Должны ли софтверные архитекторы писать код?

15 комментариев
Должны ли софтверные архитекторы писать код?

Уже достаточно много написано на тему того, должны ли софтверные архитекторы писать код, этот вопрос активно обсуждается в профессиональном сообществе. Многие полагают, что чем лучше архитектор понимает тот язык программирования, те инструменты и ту среду, для которых он проектирует, тем эффективнее он работает. Для обеспечения такой эффективности архитектор должен самостоятельно реализовать части проектируемого продукта, либо даже весь продукт целиком. Архитекторы, не пишущие код, которых иногда называют «архитекторами PowerPoint», «астронавтами от архитектуры» или сравнивают с отшельниками, запершимися в башнях из слоновой кости, с умным видом рассуждают на околотехнические темы, силясь убедить заказчиков-нетехнарей в своей компетентности. Когда же дело доходит до реальной работы, они перекладывают возникающие проблемы на плечи разработчиков. Дошло до того, что уже сформировался специальный паттерн организации труда («архитектор тоже реализует») и соответствующий антипаттерн («архитектор не пишет код»). Противники участия архитекторов в разработке считают, что архитектор, занимающийся разработкой, не может как следует сосредоточиться на проектировании и упускает крупные проблемы, которые могут возникать в долгосрочной перспективе. Понимание всей системы не обязательно требует вникания в детали. Кроме того, поскольку системы масштабируются и диверсифицируются, на их реализацию уходит чересчур много времени, и архитектор слишком разменивается по мелочам. Итак, должны ли всё-таки архитекторы писать код?      

Рассмотрим этот вопрос с разных сторон

Как и при случаях с другими сложными проблемами, необходимо разобраться в смысле вопроса, вынесенного в заглавие статьи. Он может означать: «Должен ли архитектор писать код?», «Должен ли архитектор всегда прототипировать или реализовывать собственные интерфейсы?» либо «Должен ли архитектор в принципе уметь писать код?». Более вольная трактовка данного вопроса: «Является ли программирование наилучшим или единственным способом стать архитектором?» или «Могут ли люди без навыков программирования стать хорошими архитекторами?»

Кроме того, необходимо дать точное определение термина «софтверный архитектор». Канадский архитектор Витольд Рыбчинский (строитель, а не программист), в 1989 году написал книгу «Самый прекрасный дом в мире», в которой есть следующий отрывок:

На протяжении веков различия между квалифицированными каменщиками, строителями, занимающимися отхожим промыслом, столярами, дилетантами, одаренными любителями и архитекторами были почти не определены. Например, многие шедевры ренессансной архитектуры были спроектированы непрофессиональными архитекторами. Брунеллески учился на ювелира, Микеланджело был скульптором, Леонардо да Винчи — живописцем, Альберти — юристом. Лишь Браманте, хотя и был художником, также получил систематическое образование в области архитектуры. Этих людей именуют архитекторами, так как, среди прочего, они занимались архитектурой. Это тавтология, которая ничего не объясняет».

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

Должен ли архитектор уметь писать код? Да, не только читать, но и писать, поскольку эти навыки помогают архитектору:

  1. Проверять, насколько написанный разработчиками код соответствует дизайну и обнаруживать возникающие отклонения.
  2. Изучать изменения или новые фичи, появившиеся в программе. Если архитектор переходит к работе над новым проектом, то он сможет быстрее ознакомиться с сутью этого проекта именно на уровне кода.
  3. Самостоятельно писать код, подтверждающий правильность тех или иных спроектированных концепций или прототипов. Рабочая демо-версия выглядит гораздо более убедительно, чем сложная блок-схема. Как правило, рабочая версия позволяет давать более точные оценки продукта. Правда, необходимо следить за тем, чтобы заинтересованные лица без технического образования не доверяли такой версии всецело — впрочем, это касается любого прототипа.
  4. Предложить команде еще пару умелых рук, которые помогут спасти проект в случае аврала.
  5. Более спокойно относиться к багам, поскольку практикующий архитектор, вероятно, сам совершал в прошлом подобные ошибки. Как минимум, архитектор будет лучше понимать, ошибки какого типа наиболее вероятны в такой системе.

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

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

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

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

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

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

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

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

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

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

Про мере все более широкого распространения гибких методологий работа архитектора уже не сводится к обычной разработке общего плана и выдаче его разработчикам «на-гора». Даже те архитекторы, которые ранее не покидали своих башен из слоновой кости, все более активно вовлекаются в решение частных проблем, поскольку некритичные проблемы все чаще откладываются «на потом», а дизайн становится итеративным. Например, если организация придерживается Scrum-методологии, то ее архитекторы должны участвовать как минимум в планировании, проверке и ретроспективном анализе. (Некоторые архитекторы могут переходить на другие проекты или даже вообще не иметь полного представления о текущем проекте  такой антипаттерн именуется «архитекторы играют в гольф». Однако такие проблемы возникают из-за неправильной организации труда в компании и не связаны с тем, занят ли архитектор написанием кода).

Многие разработчики также свысока смотрят на «PowerPoint-архитектуры». При этом, однако, многие забывают, что архитектор должен уделять коммуникации не менее пристальное внимание, чем разработке, а полноценная реализованная архитектура никак не помогает в работе нетехническим заинтересованным лицам, тестировщикам, специалистам по локализации, техническим писателям и т.д. Разумеется, так называемые «стратосферные PowerPoint-архитектуры» не заменяют высокоуровневого дизайна, который может быть реализован самим архитектором, однако архитектор представляет продукты и выступает от лица разработчиков за пределами команды, а разработчик воспринимает любую деятельность, не связанную с написанием кода, как непродуктивную. В конце концов, PowerPoint-архитекторы занимают свою нишу, но разработчиков следует считать не менее важными «клиентами» архитектора, нежели заказчиков.

Должен ли архитектор писать код? Этот вопрос не имеет однозначного ответа, его требуется решать отдельно в каждом конкретном случае. Архитекторы могут прототипировать проекты, отличающиеся высокой степенью риска, экспериментировать с новыми библиотеками или инструментами. При этом архитектор может целиком делегировать другим людям проектирование и реализацию хорошо понятных компонентов, не связанных с серьезными рисками. Вопрос следует сформулировать иначе: «Как архитектору стать успешным?» В таком случае требуется признать, что успешный архитектор умеет управлять рисками и сводить их к минимуму. Архитекторы часто бывают хорошими кодерами, но хороший кодер далеко не всегда годится в архитекторы.

Энтони Лэнгсуорт

Источник

Горячие события

Конкурс EY Entrepreneur Of The Year 2020
31 мая — 31 мая

Конкурс EY Entrepreneur Of The Year 2020

GoWayFest 4.0
11 июля — 11 июля

GoWayFest 4.0

Минск

Читайте также

Данные смартфонов помогают мониторить пандемию, приватность отменяется
Данные смартфонов помогают мониторить пандемию, приватность отменяется

Данные смартфонов помогают мониторить пандемию, приватность отменяется

Государства пытаются различными способами, в том числе с помощью информационных технологий, замедлить распространение коронавируса. По данным сайта Top10VPN, который собирает такие примеры, на 31 марта методы цифрового трекинга используются в 20 странах, продвинутые технологии видеонаблюдения за перемещением граждан — в 7 странах.
1 комментарий
Когда перевода недостаточно, или что бизнесу может дать локализация
Когда перевода недостаточно, или что бизнесу может дать локализация

Когда перевода недостаточно, или что бизнесу может дать локализация

Создать бизнес — гордость для каждого. А создать успешный бизнес, который можно масштабировать на другие страны, — это непростая задача и большая ответственность. И, как в любом ответственном деле, здесь много подводных камней. Один из них — локализация сайта и приложения для бизнеса. Компания Alconost рассказывает, что такое локализация, чем она отличается от простого перевода, как влияет на перспективы компании и что бизнес может получить благодаря локализации.
10 бесплатных приложений для домашних тренировок
10 бесплатных приложений для домашних тренировок

10 бесплатных приложений для домашних тренировок

Перевели подборку приложений от Android Police, которые помогут поддерживать тело в хорошей форме без спортзала.
1 комментарий
10 научных и технологических музеев, которые можно посетить онлайн
10 научных и технологических музеев, которые можно посетить онлайн

10 научных и технологических музеев, которые можно посетить онлайн

Подборка виртуальных туров по музеям в разных странах от Interesting Engineering.
1 комментарий

Обсуждение

1

Должен.

0

Обязан и не просто программировать, а делать это в парах, подтягивая коллег, тогда само понятие софтвенный архитектор размоется и будет делегировано на кучу высококлассных разработчиков, где каждый имеет право голоса. Как в любом серьёзном open source проекте.

0

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

0

То, что архитектор должен иметь приличный технический бэкграунд не должно подлежать сомнению. А вот программировать самостоятельно... ИМХО опционально. Если есть необходимость из-за недостатка квалифицированных кадров, если есть желание поддерживать на высоком уровне собственние технические скилы... На самом деле, что бы проектировать сложные решения, причём грамотные решения, архитектору стоит тратить своё время максимально эффективно, а кроме набивания кода есть еще масса векторов приложения усилий: изучение существующих решений, паттернов, тенденций развития технологий/бизнесов... Аналогично как и архитектору в строительстве будет лишним класть кирпичи самостоятельно - просто потому, что это не самое эффективное использование его навыков и способностей.

Хотя всё зависит от масштаба. Для кого то сайт-визитку сваять дело пары часов "на коленке", а для кого то это серьёзный проект...

0

про тех кто не программирует сам говорят: "страшно далеки они от народа"

0

"Хоть горшком назови, только в печку не ставь" (с)
Если есть в команде люди, которые всеръёз считает, что архитектор просто обязан писать код, то тут как минимум два варианта: либо проект не настолько масштабен, что позволяет архитектору лезть писать код; либо такие люди недостаточно зрелы, как разработчики.

Просто умиляет, что с одной строны все стебаются над тем, что сами_знает_кто на селекторном совещании порой чуть не картошку перебирает дистанционно (мол есть дела и поважнее), а с другой стороны всерёз призывают ровно к этому же...

4

Тогда два вопроса:
1. Теряются ли со временем навыки программирования если не программировать?
2. Обязан ли архитектор быть в прошлом программистом ???

1

1. да
2. очень желательно

но как это связано с функциональными обязанностями архитектора?

Но да ладно, видимо мы по разному понимаем роль архитектора на проекте. ИМХО видимо аутсорсные проекты, львиная доля архитектоур для которых разрабатывается ТАМ, привели наших программистов к выводу, что архитектор - это нечто среднее между тимом и ПМмом...

0

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

-2

Научился ездит на велосипеде, год-два не катался - разучился?

Ну да ладно. Пусть архитектор программирует, причём желательно на ассемблере, что бы так сказать совсем уж в теме был.

2

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

Максим Мельников
Максим Мельников Developer в Wargaming / Гейм Стрим
4

должен/не должен... какой-то теоретический вопрос из мира пони... на практике главный вопрос: есть у его на это время или нет

1

судя по заглавному фото к статье архитектор должен много пить, тащить все в "семью" и иметь неординарные деструктивные способности.

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
6

ISO/IEC 42010:20071 defines “architecture” as:
“The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
я бы сказал, нужно больше не код писать а скорее системно мыслить :) но я вообще так, мимо проходил, пусть лучше авторитетные парни выступят про то, как на самом деле надо.

0

Спасибо за перевод, но статья слишком очевидная получилась. Предлагаю рассмотреть следующие темы: "Должен ли разработчик уметь тестировать приложения?", "Зачем пилоту уметь прыгать с парашютом?", "Терапевт: перевязывание ран. За и против."

А если серьезно, то одной из задач архитектора является исследование новых технологий, которые появляются на рынке. Как он, простите, будет их проверять на пригодность без написания кода? К гадалке пойдет?