Уже достаточно много написано на тему того, должны ли софтверные архитекторы писать код, этот вопрос активно обсуждается в профессиональном сообществе. Многие полагают, что чем лучше архитектор понимает тот язык программирования, те инструменты и ту среду, для которых он проектирует, тем эффективнее он работает. Для обеспечения такой эффективности архитектор должен самостоятельно реализовать части проектируемого продукта, либо даже весь продукт целиком. Архитекторы, не пишущие код, которых иногда называют «архитекторами PowerPoint», «астронавтами от архитектуры» или сравнивают с отшельниками, запершимися в башнях из слоновой кости, с умным видом рассуждают на околотехнические темы, силясь убедить заказчиков-нетехнарей в своей компетентности. Когда же дело доходит до реальной работы, они перекладывают возникающие проблемы на плечи разработчиков. Дошло до того, что уже сформировался специальный паттерн организации труда («архитектор тоже реализует») и соответствующий антипаттерн («архитектор не пишет код»). Противники участия архитекторов в разработке считают, что архитектор, занимающийся разработкой, не может как следует сосредоточиться на проектировании и упускает крупные проблемы, которые могут возникать в долгосрочной перспективе. Понимание всей системы не обязательно требует вникания в детали. Кроме того, поскольку системы масштабируются и диверсифицируются, на их реализацию уходит чересчур много времени, и архитектор слишком разменивается по мелочам. Итак, должны ли всё-таки архитекторы писать код?
Как и при случаях с другими сложными проблемами, необходимо разобраться в смысле вопроса, вынесенного в заглавие статьи. Он может означать: «Должен ли архитектор писать код?», «Должен ли архитектор всегда прототипировать или реализовывать собственные интерфейсы?» либо «Должен ли архитектор в принципе уметь писать код?». Более вольная трактовка данного вопроса: «Является ли программирование наилучшим или единственным способом стать архитектором?» или «Могут ли люди без навыков программирования стать хорошими архитекторами?»
Кроме того, необходимо дать точное определение термина «софтверный архитектор». Канадский архитектор Витольд Рыбчинский (строитель, а не программист), в 1989 году написал книгу «Самый прекрасный дом в мире», в которой есть следующий отрывок:
На протяжении веков различия между квалифицированными каменщиками, строителями, занимающимися отхожим промыслом, столярами, дилетантами, одаренными любителями и архитекторами были почти не определены. Например, многие шедевры ренессансной архитектуры были спроектированы непрофессиональными архитекторами. Брунеллески учился на ювелира, Микеланджело был скульптором, Леонардо да Винчи — живописцем, Альберти — юристом. Лишь Браманте, хотя и был художником, также получил систематическое образование в области архитектуры. Этих людей именуют архитекторами, так как, среди прочего, они занимались архитектурой. Это тавтология, которая ничего не объясняет».
Схожая проблема возникает и в случаях, когда мы пытаемся определить суть профессии архитектора-программиста. Поскольку эта роль не имеет четких признаков и не отделяется от решения других прикладных задач, архитектором может себя называть любой специалист, занимающийся проектированием программ или других систем, связанных с IT. Под такую дефиницию архитекторов подпадают многие разработчики и техлиды. В этой статье я беру за основу определение, предложенное в посте Саймона Брауна, согласно которому софтверный архитектор отвечает за высокоуровневое проектирование, выполнение требований, не связанных с функционированием отдельных компонентов и за техническое представление о процессе.
Должен ли архитектор уметь писать код? Да, не только читать, но и писать, поскольку эти навыки помогают архитектору:
- Проверять, насколько написанный разработчиками код соответствует дизайну и обнаруживать возникающие отклонения.
- Изучать изменения или новые фичи, появившиеся в программе. Если архитектор переходит к работе над новым проектом, то он сможет быстрее ознакомиться с сутью этого проекта именно на уровне кода.
- Самостоятельно писать код, подтверждающий правильность тех или иных спроектированных концепций или прототипов. Рабочая демо-версия выглядит гораздо более убедительно, чем сложная блок-схема. Как правило, рабочая версия позволяет давать более точные оценки продукта. Правда, необходимо следить за тем, чтобы заинтересованные лица без технического образования не доверяли такой версии всецело — впрочем, это касается любого прототипа.
- Предложить команде еще пару умелых рук, которые помогут спасти проект в случае аврала.
- Более спокойно относиться к багам, поскольку практикующий архитектор, вероятно, сам совершал в прошлом подобные ошибки. Как минимум, архитектор будет лучше понимать, ошибки какого типа наиболее вероятны в такой системе.
Создавая код, архитектор начинает пользоваться уважением среди разработчиков. Печально известно, с каким сарказмом разработчики могут относиться к нетехнарям. Поэтому если архитектор умеет писать код — хотя бы только в качестве иллюстрации предлагаемых концепций, либо умеет грамотно отрецензировать чужой код, то разработчики легко примут его в свой круг. Если архитектор на практике использует среду разработки и обращается к исходному коду, то может сам опробовать новые версии, не дожидаясь следующей сборки или релиза. Любые серьезные проблемы, возникающие со сборкой, средой разработки или при управлении кодом, сразу же становятся очевидны и для архитектора.
Следует учитывать, что проверка кода не заменит бесед с разработчиками, поскольку регулярная коммуникация между программистами-кодерами и архитекторами помогает выстроить взаимное уважение. Без такого общения разработчики вполне могут воспринимать архитектора как помеху или даже угрозу, которую лучше обходить. Кроме того, разработчики зачастую разбираются в предметной области лучше, чем архитектор — даже если архитектор умеет читать код. Однако необходимо соблюдать баланс между самодостаточностью архитектора и откровенным разбазариванием времени разработчика.
Зачастую архитекторам приходится выступать арбитрами в спорах между разработчиками. Например, команда может найти более оптимальный способ решения проблемы, чем предложено в проекте. Иногда оказывается, что реализовать предложенный дизайн сложнее, чем казалось на этапе проектирования. Кроме того, архитекторы иногда становятся наставниками или тренерами для разработчиков, либо выступают в роли внутрикорпоративных консультантов и следят за выполнением процесса, контролируют качество, организуют автоматизацию или справляются со смежными проблемами. Если архитектор понимает код, то может формировать о нем собственное обоснованное мнение, а не гадать, аргументы какого из разработчиков кажутся более убедительными.
Должен ли архитектор тратить большую часть рабочего времени на написание боевого кода (как правило — реализовывать собственную архитектуру?) Если архитектор занимается такой работой, то так гарантируется, что предложенный проект реализуем с применением имеющихся инструментов и среды разработки. Подобная деятельность может приводить архитектора к новым находкам, позволяет оптимизировать дизайн и более точно его оценивать. Наконец, реализацию выполняет человек, наиболее полно представляющий себе дизайн — а значит, исключаются недопонимания, которые могут возникать на уровне профессиональной коммуникации.
Однако архитектор может перейти к реализации (глубокому продумыванию проекта) до того, как рассмотрит все альтернативные варианты решений (широкое обдумывание). Архитектор может слишком сильно поддаваться влиянию уже имеющихся реализаций, либо чрезмерно увлекаться сохранением своей версии кода, отвергая необходимые улучшения. Непосредственно занимаясь написанием кода, архитектор отвлекается от решения более высокоуровневых задач — в частности, от долговременного планирования, общения со всеми заинтересованными сторонами и рецензирования кода других разработчиков.
Кроме того, немаловажная задача архитектора заключается в борьбе за переиспользование кода, соблюдение требований безопасности и реализацию требований, не связанных непосредственно с функционалом. Если архитектор вынужден заниматься прототипированием или реализацией своего дизайна, то это может подталкивать его к ненужным компромиссам, на которые команда идти не должна. Дело не в том, что архитектору противопоказаны компромиссы — в конце концов, распространено мнение, что умелое нахождение компромиссов есть важнейшая черта искусства проектирования. Но архитектор должен уметь находить правильные компромиссы, а не те, на которые приходится идти на начальных этапах реализации. Так или иначе, разработчики, скорее всего, перепишут большую часть кода, подготовленного архитектором.
Действительно, чем больше архитектор занимается коммуникацией, анализом требований, работой с заинтересованными лицами и прочей нетехнической работой, тем выше вероятность, что у него атрофируются навыки практической разработки. Это не такая большая проблема, поскольку архитектор приносит пользу компании другими своими навыками. Однако архитектор должен заботиться о том, чтобы его навыки разработки не терялись. Например, ему стоит заниматься глубокими техническими исследованиями, вести собственные проекты, либо по мере сил участвовать в других проектах. При этом основное внимание архитектор должен уделять возможностям, ограничениям и пограничным случаям, а не скорости разработки или полному пониманию деталей.
Возможны проблемы, если организация продвигает на роли архитекторов сильнейших разработчиков, а не тех людей, которые способны эффективно общаться и работать с высокоуровневыми абстракциями. Возникают шероховатости, когда такие архитекторы пытаются «руководить с фронта», реализуя собственные проекты, а не поручая эти задачи коллегам. На позицию архитектора больше подходят как раз те разработчики, которые могут похвастаться сильными социальными навыками.
Многие ошибочно принимают недостаточно активное написание кода за «слабую обратную связь». Можно предположить, что непрототипированную архитектуру будет сложно реализовать или поддерживать. Однако при необходимости прототипировать архитектуру может старший разработчик или техлид. В таком случае можно наладить взаимодействие между архитекторами и разработчиками, а также гарантировать, что все получают достаточно полную информацию о дизайне. Другой вариант — использовать архитектуру совместно с коллегами, уже имеющими опыт реализации подобных систем, либо с такими разработчиками и архитекторами, которые занимаются интеграцией продуктов. Если же мы требуем от архитектора заниматься более глубокой реализацией предложенной им архитектуры, а не просто концептуальной подготовкой, то такая работа плохо масштабируется, особенно если речь идет о больших и сложных продуктах.
Аналогично, если архитектор не пишет код, то многие ошибочно полагают, что его работу сложно отслеживать. Архитекторам требуется подготавливать проекты, которые одобряются (официально или неофициально) не только заинтересованными лицами, но и разработчиками. Разработчики не должны одобрять документ, который не отвечает их потребностям. Следует указывать на проблемы или ошибки в дизайне. Некоторые изменения вполне ожидаемы, но если возникает крупная ошибка либо ошибка, которая приводит к серьезным убыткам, то это вина архитектора. Однако если архитектор реализует предложенный проект на уровне кода, он не может гарантировать полного отсутствия ошибок в проекте.
Про мере все более широкого распространения гибких методологий работа архитектора уже не сводится к обычной разработке общего плана и выдаче его разработчикам «на-гора». Даже те архитекторы, которые ранее не покидали своих башен из слоновой кости, все более активно вовлекаются в решение частных проблем, поскольку некритичные проблемы все чаще откладываются «на потом», а дизайн становится итеративным. Например, если организация придерживается Scrum-методологии, то ее архитекторы должны участвовать как минимум в планировании, проверке и ретроспективном анализе. (Некоторые архитекторы могут переходить на другие проекты или даже вообще не иметь полного представления о текущем проекте — такой антипаттерн именуется «архитекторы играют в гольф». Однако такие проблемы возникают из-за неправильной организации труда в компании и не связаны с тем, занят ли архитектор написанием кода).
Многие разработчики также свысока смотрят на «PowerPoint-архитектуры». При этом, однако, многие забывают, что архитектор должен уделять коммуникации не менее пристальное внимание, чем разработке, а полноценная реализованная архитектура никак не помогает в работе нетехническим заинтересованным лицам, тестировщикам, специалистам по локализации, техническим писателям и т.д. Разумеется, так называемые «стратосферные PowerPoint-архитектуры» не заменяют высокоуровневого дизайна, который может быть реализован самим архитектором, однако архитектор представляет продукты и выступает от лица разработчиков за пределами команды, а разработчик воспринимает любую деятельность, не связанную с написанием кода, как непродуктивную. В конце концов, PowerPoint-архитекторы занимают свою нишу, но разработчиков следует считать не менее важными «клиентами» архитектора, нежели заказчиков.
Должен ли архитектор писать код? Этот вопрос не имеет однозначного ответа, его требуется решать отдельно в каждом конкретном случае. Архитекторы могут прототипировать проекты, отличающиеся высокой степенью риска, экспериментировать с новыми библиотеками или инструментами. При этом архитектор может целиком делегировать другим людям проектирование и реализацию хорошо понятных компонентов, не связанных с серьезными рисками. Вопрос следует сформулировать иначе: «Как архитектору стать успешным?» В таком случае требуется признать, что успешный архитектор умеет управлять рисками и сводить их к минимуму. Архитекторы часто бывают хорошими кодерами, но хороший кодер далеко не всегда годится в архитекторы.
Энтони Лэнгсуорт
Источник
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.