Если Вам Нужен Архитектор, То У Меня Для Вас Плохие Новости
Что такое «правильная архитектура» — повод для нескончаемых холиваров. Что такое «программная система» — тоже не вполне определено, т.к. надо учитывать размер системы, уровень абстракции и ширину рассмотрения. В общем, на пальцах понятно только, что это роль, и что это про архитектуру.
На практике, кстати, уровень понимания этой роли обычно именно такой. Чёрт его знает, кто это должен быть и чем заниматься. Никто ведь не лезет в описания System Architect / Solution Architect по тому же SAFe. Просто нанимают какого-то башковитого мужика и говорят: вот, будешь у нас Архитектором.
Ну, а чем обычно занимается этот Архитектор? Понятное дело, что если это какая-то громадная система уровня информационной системы министерства, или что-то с кучей интеграций — скажем, крупный проект SAP — то там бывает, что и несколько Архитекторов трудятся... в основном над документацией. И следят, чтобы все договорённости, описанные в этой документации, соблюдались. И бьют по кривым рукам коллег из параллельных структур за то, что те не соблюдают оговоренные программные интерфейсы. И пишут, пишут, пишут документацию.
Ну, а в обычной продуктовой или заказной разработке? Как роль — безусловно, Архитектор нужен вообще в любом проекте. В начале. Ну, и немного — иногда исчезающе немного — по ходу работы над проектом. Чтобы следить, не нарушаем ли принятых архитектурных решений, и иногда эти решения обновлять под давлением обстоятельств.
Но ведь бывает, что на роли Архитектора сидит действительно башковитый, опытный товарищ, и фуллтайм что-то делает сразу во всех проектах компании. И без него — никуда.
Вот это и есть первая плохая новость
Если разработчики проектов настолько некомпетентны, что не умеют / не могут выстроить архитектуру своего проекта — настолько некомпетентны, что за них это делать приходится отдельному башковитому мужичку — то какой же код они потом будут писать? Архитектор ведь не будет следить за каждой реализацией класса или интерфейса... или будет? %)
Есть такой забавный подход к разработке ПО — условно можно назвать «подход Звезда» — когда на работу берут мощного опытного парня, ставят его в центр, а вокруг образуется звезда из кодеров. Уже не разработчиков — а именно кодеров. Тимлид / Архитектор генерит UML диаграммы с детализацией вплоть до конкретных классов и интерфейсов — а кодеры бездумно реализуют его концепцию. Кодеру вообще не надо думать — за него думает Архитектор. Более того — кодер НИКОГДА и не научится думать с таким подходом. А если даже и умел когда-то думать — то со временем разучится.
А это — вторая плохая новость
Если вы централизуете принятие архитектурных решений — вам не только придётся всё глубже и глубже погружать Архитектора в каждый проект. Вы ещё и своих разработчиков разучите принимать самостоятельные решения, да и вообще думать головой.
Правда, нынче придумали микросервисы. И я тихо подозреваю, что популярность микросервисов связана именно с проблемами индустрии, а не с тем, что это такой уж офигенный подход в принципе. Если вкратце — то микросервисный подход позволяет посадить в центре Архитектора, но ему надо будет детализировать уже не на уровне классов, а на уровне модулей и интерфейсов между ними. Это супер удобно, учитывая, что все разрабы — удалёнщики, друг с другом общаются мало или вообще никак, да и живут / работают в абсолютно разных часовых поясах. Ну и ещё, положа руку на сердце, — потому что хорошего разработчика найти тяжело, воспитать ещё тяжелее, а микросервис реализовать можно и незнакомому индусу поручить.
В итоге все проблемы разработки убираются с уровня модулей — микросервисов — и перекладываются на уровень выше. На уровень согласования работы модулей, data flow, взаимного оповещения и так далее. То есть на традиционно гораздо более проблемный уровень. На котором, к тому же, приходится работать куда более квалифицированным и дорогостоящим специалистам. А уж при развёртывании всего этого колхоза у DevOps проблем столько, что из отложенных кирпичей можно каждый день строить новый дом. Зато есть куда приложить нашего Архитектора. Конечно, при этом разработчики снова будут превращаться в бездумных кодеров — ну, да это их проблемы, верно?
Есть ещё так называемые Архитекторы-Астронавты
Любители накручивать абстракции на абстракции, намазывать сложность поверх сложности, и так далее. Очень хорошо их описал Джоэль Спольски ещё в 2001м году. Ну, дейEDITствительно, вы же взяли очень умного парня на фуллтайм. Надо же ему чем-то заняться... не код же писать, в самом деле. Вот он и ходит туда-сюда, задумчивый. Продумывает очередную гениальную идею реализации стандартной, в общем-то, функциональности новым, революционным методом. Очень сложным, разумеется. Он же не дурак, чтобы делать просто. И это — третья плохая новость. Такой человек не просто будет бесполезно жрать огромную зарплату — он ещё и вреда нанесёт столько, что потом с двумя бригадами ассенизаторов не разгребёшь.
В общем, в таких надо стреля... эмм, увольнять их надо без предупреждения.
И что же делать?
На это есть два ответа: простой и сложный. Простой — брать на вооружение подход «Звезда», но делать это осознанно. Понимая, что микросервисы могут принести в дальней перспективе множество проблем. Понимая, что вы делаете своего Архитектора узким местом, бутылочным горлышком, повышая Bus Factor. Понимая, что вы низводите своих разрабочтиков до уровня кодеров, и им это не очень-то понравится. Понимая, что проблема воспитания кадров встанет ещё сильнее, и подходить к её решению придётся очень серьёзно.
Просто, не правда ли?