Как поделить архитектуру и реализацию и не поругаться

[vadimnt]

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

[a-tk]

А есть архитектуры, куда закладывается запас гибкости. Он не безграничный, но часто помогает выкручиваться в нестандартных ситуациях, не сильно или вообще не ухудшая архитектуру.

[eugef]

Если бы архитектуру разных компонентов / подсистем продумывали разные разработчики, это способствовало бы обмену опытом и развитию членов команды

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

[vadimnt]

Да, следить за согласованностью архитектуры конечно нужно. Один хороший способ этого добится — устраивать обсуждения архитектуры с участием опытных коллег. На них член команды, проработавший архитектуру, рассказывает, какую архитектуру он предлагает. Коллеги задают вопросы и предлагают улучшения. Если задуманная архитектура окажется «сырой», цикл проектирования и обсуждения повторяется.

[f2heartz]

Это, конечно, совершенно немыслимый подход для крупного софта. Если над проектом работают хотя бы 10 человек хотя бы в двух разных городах — предлагаемый подход гарантированно ведет в тупик. Во-первых, в команде ни у кого никогда не бывает равное «количество» знаний — не только сугубо профессиональных (паттерны — ООПшные, ФПшные, теория сложности, знание фундаментальной математики и конкретных рантаймов и языков программирования в привязке к конкретной операционной системе), но и «бизнес»-знаний — в первую очередь, понимание дальних перспектив сервиса, финансовой модели (на чем делаются деньги) и возможных (резких) изменений в последней. С таким разнобоем в стартовых условиях, люди просто объективно не могу «на равных» участвовать в принятии судьбоносных решений, не упоминая уже о том, что это предполагает и некоторую ответственность (большинство людей ее избегают или стремятся переложить на плечи соседа, человеческая природа — еще один фактор, о котором не пишет автор).

Поэтому на деле — архитектура всегда была и будет уделом немногих. Они будут разрабатывать framework-like core-библиотеки, распространять их через ту или иную систему управления зависимости типа nuget, npm, pip, по-возможности снабжая код хорошими комментариями и сопроводительными описаниями где-то на confluence. Еще хорошо бы, чтобы все изменения в этих библиотеках проходили через них на merge request'ах (что тоже далеко не общая практика — такие люди часто очень востребованы и у них просто нет времени уследить за всем, иначе небольшие по объему MR могут висеть неделями, что круто стопорит общий процесс разработки и в глазах менеджмента выглядит как сигнал к более отчаянным действиям). Остальное же — неизбежно будет с примесью шумов: неверные структуры данных, заведомо тупиковые алгоритмы, крайне неудачные API интерфейсов или полное их отсутствие, просто дерьмокод: все это попадает в проект не потому что нет архитектуры, тонн UML-диаграм или благословения РПЦ, а вследствие определенного уровня развития определенных разработчиков. Караван всегда идет со скоростью самого медленного верблюда.
Теперь еще немножко жизненного опыта. За мою карьеру, мои идеи заворачивали не раз. Я предлагаю гораздо более красивые архитектурные решения; пользуясь теорией сложности, показывал их значительное превосходство по сравнению с существующим подходом; демонстрировал готовые прототипы с бенчмарками; показывал научные работы уровня PhD (не мои, конечно — те, которые в свободном доступе), где эти решения обсуждались с теоретической стороны и бла-бла-бла. 95% — натыкалось на полнейшее непонимание. Либо от этого отказывались еще на этапе предварительных обсуждений и демонстрации демо, либо впоследствии делали git revert: потому что «коллегам было нипанятна». Люди в большинстве своем весьма аморфные и нелюбознательные существа и с этим приходится считаться.
Еще раз главный вывод — караван всегда идет со скоростью самого медленного верблюда. А за быстрых верблюдов нужно дорого платить.

[vadimnt]

Если над проектом работают хотя бы 10 человек хотя бы в двух разных городах — предлагаемый подход гарантированно ведет в тупик

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

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

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

Конечно, вышесказанное — точка зрения, сформированная из-за опыта работы в определенных проектах и командах. Я в основном работал над распределенными высоконагруженными системами в кроссфункциональных agile-командах. Работа в других проектах может приводить к другим точкам зрения.