От задач к системам: владение и проектирование

Если первый переход был «от части задачи к задаче целиком», то второй — «от задачи к системе».

Владение системой — ответственность за компонент целиком: его проектирование, развитие, надёжность и последствия изменений, а не только за отдельные задачи внутри.

Сдвиг масштаба

Middle отлично решает поставленные задачи. Senior отвечает за систему, в которой эти задачи возникают: за сервис, подсистему, важный кусок продукта. Разница не в размере кода, а в горизонте. Middle думает «как сделать эту задачу хорошо». Senior думает «куда движется эта система, какие задачи в ней появятся, где она треснет через год».

Проектирование как новый навык

Ключевое умение senior — превращать размытое требование в продуманный дизайн до написания кода. Это значит: уточнить требования, набросать несколько вариантов архитектуры, оценить их по критериям (надёжность, стоимость, скорость, сложность), выбрать и объяснить выбор. Подробно это разбирает курс по System Design; здесь важна сама смена режима — думать дизайном, а не сразу кодом.

Как работает под капотом

Способность видеть последствия — это построенная в голове модель системы. Senior, прежде чем менять код, мысленно прогоняет: что станет с производительностью, что с соседним сервисом, что при сбое, что при росте нагрузки в 10 раз. Эта модель появляется не от ума, а от шрамов: от пережитых инцидентов, отлаженных проблем, прочитанного кода. Поэтому опыт эксплуатации (дежурства, разбор аварий) так ускоряет рост в senior — он наполняет модель реальностью.

Перед изменением senior мысленно проигрывает:

  изменение -> производительность? -> соседние сервисы?
            -> что при сбое? -> что при росте x10? -> откат возможен?

Тренировать этот взгляд проще, чем кажется: к каждому решению добавляйте вопрос «а что потом?» и прогоняйте его на два-три шага. Добавили индекс — ускорили чтение; а что потом? Замедлилась запись. А что потом? На горячей записи это станет узким местом под нагрузкой. А что потом? Придётся переделывать в спешке во время инцидента. Три «а что потом?» обычно вытаскивают на поверхность последствие, которое в моменте было невидимым. Это дешёвая привычка, которая отличает того, кто чинит проблемы заранее, от того, кто потом героически тушит пожары.

Видеть последствия

Главный маркер senior — он замечает то, чего ещё нет на экране. «Если мы так сделаем, через полгода миграция данных станет адом». «Этот индекс ускорит чтение, но замедлит запись, а у нас запись горячая». Это не магия, а привычка достраивать второй и третий порядок последствий. Тренируется вопросом «а что потом?» к каждому решению.

Документация решений и ADR

Признак senior, владеющего системой, — он фиксирует не только код, но и причины архитектурных решений. Для этого используют ADR (Architecture Decision Record) — короткую запись формата «контекст, рассмотренные варианты, выбор и его обоснование, последствия». Через год, когда кто-то спросит «почему здесь так странно сделано», ADR ответит вместо вас, и команда не наступит на те же грабли заново. Это часть владения системой во времени: вы заботитесь не только о сегодняшнем коде, но и о будущих инженерах, включая будущего себя.

Способность видеть последствия растёт быстрее всего у тех, кто участвует в эксплуатации: дежурит, разбирает инциденты, чинит то, что упало ночью. Каждый разбор аварии добавляет в вашу модель системы реальный пример того, как и почему ломается прод. Поэтому, если хотите ускорить переход в senior, не избегайте дежурств и пост-мортемов — это не наказание, а самый концентрированный источник опыта о последствиях.

Частые ошибки

• Сразу кодить без дизайна. На уровне системы цена неверного решения высока; полчаса проектирования экономят недели.
• Видеть только первый эффект. Решение «ускорим чтение» без взгляда на запись и будущее — это ловушка.
• Считать систему «не моей зоной». Senior достраивает ответственность до системы, даже если формально владеет лишь куском.

Итоги

• Второй переход — от задачи к владению системой во времени.
• Senior проектирует решение до кода, а не кодит сразу.
• Способность видеть последствия — это модель системы, наполненная опытом.
• Тренируйте взгляд на второй и третий порядок последствий.