🌿 Систем дизайн в реальной жизни: Как предлагать свои изменения

В этом посте мы разберем что такое процесс принятия решений и как внедряют и выбирают технологии в зрелых командах.

Недавно мне написали в лс и попросили совет в проблеме, что очень сложно доказывать команде какие-то архитектурные проблемы и точки роста. Разработчик хотел показать команде, что очень сложно работать без паттернов проектирования и СОЛИД принципов в проекте, но не мог найти аргументы.

Только в маленьких командах можно занести какие-то иновации или внести изменения легко. Зависимостей немного, проект небольшой. В крупных же это становится в разы сложнее. Времени на синхронизацию и кодревью съедает больше, чем на написание кода. Если твоя работа затрагивает другие команды, то нужно собрать их апрувы еще до того как напишешь код. Ибо своим желанием причинить добро ты можешь сломать всем проект.

Не нравится вам архитектура проекта, вынеси свои предъявы и предложи решения. Пора переходить на SwiftUI? Также создай обсуждение и собери аргументы почему именно он сделает жизнь лучше.

Для того, чтобы эти обсуждения были конструктивными и эффективными, а ты не бегал по сообщениям и тредам, придумали специальные процессы. Процессы принятия решений.

📺 Какие же инструменты помогают согласовать и синхронизировать изменения в реальной жизни?

Самый частый инструмент для сбора требований — это TDR.

Technical Design Review — это специальный процесс, который помогает эффективно проработать фичу, до того как ты начнешь ее кодить. Именно здесь и нужны все навыки системного дизайна.

Для многих кажется, что это можно сделать на кодревью. Но это крайне опасное заблуждение. Этап кодревью — это когда ты уже написал код, запланировал спринт и закомитился на сроки. И вот ты потратил кучу времени, сказал своему менеджеру что твоя фича будет к такому-то сроку, а на кодревью тебя завернули и дали под жопу, что ты сделал дичь и никого об этом не предупредил. Тебя либо завернули назад и ты подвинул сроки, либо со слезами умоляешь что в будущем все перепишешь. Спустя же время все забыли что там писали в комментах твоего реквеста и твой код остался вечным легаси, который никогда не перепишут.

Индустрия придумала как бороться с этим и ввела новый процесс, который помогает хорошо запроектировать фичу, прежде чем писать код. Ведь это самое главное качество программиста — сначала думать, а потом делать.

Теперь, прежде чем приступить к разработке, многие бигтехе очень много думают: учитывают зависимости других команд; последствия; сроки и трейдоффы. А главное, это все влияет на качество твоего решения, которое в итоге пойдет в прод.

Они собирают большой документ с описанной текущей проблемой, предлагаемыми решениями (чаще от 2 до 4), отмечают всех заинтересованных и получают зеленые или красные флаги для раскатки. Все в одном документе для сохранения истории и фокуса.

Только после этого можно приступать к реализациям.

Подробнее о tech design review можно почитать здесь:
- Tech Design Review в Авито
- Technical Design Review (TDR)
- Technical Design Reviews at Marfeel