ПОСТРОЕНИЕ ДИАГРАММ

Мой первый опыт работы лидом проходил под эгидой: "Я постараюсь выпустить максимально крутой проект с точки зрения разработчика".

Пайплайн работы был такой:
1️⃣ Документация от ГД попадает на оценку разработчикам
2️⃣ Разраб оценивает фронт работ в условных единицах по системе poker planning
3️⃣ Когда задача берется в работу, набрасывается диаграмма классов, которая осматривается и approve'ится с моей стороны. Дорабатывается по требованиям.
4️⃣ Пишется код через TDD
5️⃣ Создается Pull Request и код попадает мне на ревью.
Проверяется что все принципы SOLID соблюдены и в коде нет явных ошибок.
6️⃣ PR так же прогоняется через SonarQube (статический анализатор кода), который подсказывает дополнительно где мы накосячили
7️⃣ Фича проверяется мной в редакторе
8️⃣ Вносятся правки, фича заливается в develop

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

А суть всей разработки такая:
🔸 Делать обговоренный объем работы в обозначенное время

Вот перед тем как читать, давайте разомнем голову вопросом: "Какие шаги вы бы убрали/изменили, чтобы максимально приблизится к сути?"

Ответ:
3,6 можно смело выкидывать
2 зависит от вашего PM'а
4 TDD убрать
А 7 отдать QA

Как можно догадаться, умение составлять диаграммы — не обязательный навык для разработчика.
Это приятное дополнение, которое помогает в коммуникациях:
🔸 С разработчиками на другом языке программирования
🔸 Между разработчиками в команде - через наглядное объяснение как стоит подходить к решению/реализации задачи
🔸 С DevOps инженерами.
Можно очень легко сломать копчик от кол-ва сервисов.
Потому общение диаграммами и умение быстро их накидывать, значительно ускорит работу.
Например у нас был DevOps инженер из Малайзии, где все изменения мы всегда согласовывали через схемы, чтобы убедиться что мы правильно поняли друг друга 😊

Единственное что нужно знать про диаграммы чтобы комфортно с ними работать:
🔸 Отличие имплементации, агрегации и композиции. Это добавит всем диаграммам осмысленности
🔸 Другой человек, скорее всего, так же как и вы не разбирается в тонкостях построений диаграмм
Так что забейте на все связи и правильно донесите свою мысль другому человеку 📞

Почему так? На мой взгляд есть пара объективных причин:
🔸 Диаграммы не содержат логики
🔸 Очень сложно отразить адекватно все связи с реальным классом так, чтобы это было удобно воспринимать
🔸 Диаграммы устаревают так же быстро, как код, а для поддержки их в актуальном состоянии времени нужно чуть ли не меньше, чем само написание кода

#проект_в_разработке@UniArchitect