Должны ли архитекторы приложений писать код?
Это часто задаваемый вопрос, который имеет мнения с обеих сторон. Те, кто за, будут спорить:
- Чтобы разработать систему для кодировщиков, вы должны понимать, как кодировать (и кодировать)
- Вы не можете спроектировать систему, не зная, что происходит на уровне земли
- Архитектура - это не только дизайн с широкими штрихами, но и адаптация к меняющимся потребностям на уровне кода.
с другой стороны,
- Архитектура является высокоуровневой ролью и не должна заботиться о деталях реализации
- Кодирование - это детально ориентированная, не требующая усилий функция, которая противоречит управлению рисками, широкому взгляду на природу архитектуры.
- Архитектура - это управление техническими рисками, а не внедрение
- Архитектура - это лидерство. Сложно вести сзади
По моему опыту, архитекторы не должны тратить много времени на кодирование, а должны поддерживать связь с базой кода, в первую очередь, через общение с ведущими разработчиками, анализ и встречи. Если вы тратите много времени на программирование, вы теряете из виду проблемы высокого уровня и становитесь неэффективными в управлении техническим риском.
22 ответа
Даже если ваш аргумент против кодирования верен, я думаю, что для команды разработчиков важно уважать вас и ваши дизайнерские решения. Если вы "страдаете от последствий" ваших архитектурных решений вместе с ними, то у них гораздо меньше шансов подвергнуть их сомнению.
Я все время вижу архитекторов, которые не имеют отношения к программированию и чьи команды разработчиков это знают. Они не получают большого уважения.
Ab-так frickin-лютно
Нет ничего хуже, чем Архитектор, который потерял связь с реальностью.
Это часть работы, чтобы держать ноги на земле, а голову в облаках.
Просто чтобы дать два моих цента (и мое видение "архитекторов")
Я считаю, что есть несколько типов архитекторов, каждый в своем домене:
бизнес-и функциональные архитекторы: они занимаются бизнес-операциями и рабочими процессами функций, и им на самом деле не следует кодировать, потому что они должны быть в состоянии абстрагироваться от любого вида реализации, и они должны создавать функциональные спецификации, которые оставляют техническое решение открытым,
Прикладные архитекторы: они делят функциональную область (например, "анализ прибылей и убытков") на приложения (например, "процессор портфеля", "модуль запуска", "диспетчер", "графический интерфейс"). Им не нужно кодировать, но они должны быть прежним кодером, чтобы иметь четкое представление о технических проблемах, которые должны решать их архитектуры. Их основной навык - не кодирование, а выслушивание технических коллег, чтобы выбрать правильное решение. Затем они произведут техническую реализацию, которая должна быть реализована (закодирована).
технические архитекторы: они отвечают за выбор и / или реализацию технических структур (которые являются общими для любого функционального проекта, такого как KPI, ведение журнала, управление исключениями), и они должны абсолютно кодировать (и кодировать хорошо), так как их компоненты будут используется всеми другими функциональными командами.
архитекторы разработки (эй, VonC;)): отвечая за инструменты и процессы разработки, а также за технологические исследования, они должны кодировать и любить кодирование.
Поэтому я считаю, что нет только одного ответа: это зависит от вашей архитектурной области и опыта: когда дело доходит до "архитекторов приложений", я считаю, что три последние категории могут иметь разный опыт кодирования...
Я думаю, что роль архитектуры меняется. Я вижу все меньше и меньше архитекторов башен из слоновой кости, которые разрабатывают целую систему для простых программистов, чтобы реализовать ее в процессе водопада.
При выполнении итеративных проектов коммуникация между архитекторами и программистами становится более важной. Архитектор является частью команды и должен уметь справляться с изменяющимися требованиями и новыми идеями вместе с программистами. В таких ситуациях работа архитектора и программиста более тесно связана. Я видел команды, в которых разработчики взяли на себя роль архитекторов, которые предлагают хорошо продуманные архитектуры для действительно сложных решений.
редактировать В ответ на комментарий
Я думаю, что различие между приложением, решением и корпоративным архитектором несколько искусственно и во многих случаях не совсем подходит. Роли, такие как архитектор безопасности, архитектор данных и т. Д., Дают гораздо более четкое разграничение между обязанностями. Вы можете посмотреть здесь для получения более подробной информации http://stevendwright.home.comcast.net/~stevendwright/ArchRoles.htm
Кстати, прочитав ваш вопрос еще раз, я заметил, что многие аргументы против архитекторов кодирования, по-видимому, указывают на сильную управленческую / руководящую роль архитектора. Я думаю, что это хорошая идея разделить роли управления и архитектуры. Лучше, чтобы ваши технические специалисты делили свое время между кодированием и архитектурой, чем между управлением и архитектурой.
Да. Архитекторы программного обеспечения, которые годами не писали код, теряют связь с реалиями создания продукта. Они начинают выпускать грандиозные проекты с все более высокими уровнями абстракции, которые, похоже, продолжают пропускать даты их кораблей.
Каждый проект, над которым я работал, включал в себя архитектора, который не тратил значительную часть своего времени на работу с кодом, имел проблемы из-за отсутствия практических знаний.
Это включает в себя проекты, где я был этим архитектором:-)
Теперь это личный большой красный флаг.
Я согласен со всеми аргументами в пользу архитекторов, которые пишут код. Аргументы против не подходят мне.
Код должен абстрагироваться от концепций высокого уровня, а также от низкого уровня в приложении. Если дизайн и код не интегрированы на всех уровнях, решение будет неоптимальным.
Что касается "Кодирования - это детально ориентированная, понятная функция, которая противоречит управлению рисками, широкому взгляду на природу архитектуры" - по моему опыту, широкий взгляд - и управление рисками особенно - делают для лучших программистов не хуже:-)
"Архитектура - это управление техническими рисками, а не их реализация" - не так. Речь идет об управлении рисками и их реализации (и множестве других вещей).
"Архитектура - это лидерство. Трудно вести сзади" - почему кодирование оставляет вас позади? Лично я считаю, что лучшее место для руководства - это люди, с которыми ты работаешь.
Я (кажется, я) архитектор, кодирование - вот что делает эту работу увлекательной.
Затем вы видите, что ваши идеи воплощаются в жизнь, вы видите, как работает ваш дизайн, и вы видите ошибки в дизайне (в любом случае, слишком поздно, но в следующий раз...)
Я не думаю, что они должны кодировать все в приложении. Но им нужно дать некоторые задачи. Некоторые "архитекторы" - это в основном хаки без технического опыта, которые выдают себя за "легендарных программистов" и проектируют системы, которые добавляют недели или месяцы к объему работы, которую вам пришлось бы выполнять, если бы у вас не было архитектуры. Если они не могут писать код, у них нет деловой роли в этой роли... Потому что идея заключается в архитектуре, которая должна облегчить разработку и сопровождение приложения. Но если архитектор не может развиваться, как он или она знает, как создать архитектуру?
Кроме того, даже лучшие архитекторы принимают плохие решения. Иногда что-то выглядит отлично на белой доске, но в действительности архитектурное решение в итоге делает вещи намного сложнее, чем они должны быть. Если архитектор должен съесть свою собачью еду (и использовать архитектуру), он более склонен хотеть исправлять плохие решения или строить обходные пути. Также, касаясь кода, они хотя бы немного знакомы с ним. Так что, если разработчик приходит к ним с проблемой кодирования, глаза архитектора не останутся незамеченными, поскольку он / она увольняет разработчика и говорит, что разработчик делает это неправильно, но не предлагает понимания правильного способа сделать это.
Архитектор не должен делать большие проекты в базе кода. Но они должны, по крайней мере, выполнять небольшие задачи внутри базы кода, которые заставляют их использовать свою собственную архитектуру. Также небольшие задачи будут, вероятно, включать чтение кода других людей, чтобы дать им представление о том, как люди используют архитектуру и можно ли что-то сделать для ее улучшения.
Есть архитекторы и есть ИТ-стратеги. Если вы ведете интеграционный проект с участием 500 человек в нескольких отделах, то нет, он будет мешать. Если вы занимаетесь разработкой и внедрением нескольких десятков человек в проекте разработки, тогда да. В противном случае у вас будет гораздо меньше шансов получить адекватное представление о повседневной реальности работы с вашей архитектурой.
Как заявил Влион, если задавать этот вопрос в сообществе, в котором доминируют разработчики, это означает, что ответы будут перекошены в сторону "да".
Как кто-то, у кого есть "архитектор" в его названии работы, но кто также недавно был награжден значком "Заслуженный инженер", моя преданность разрывается. В целом, я думаю, что кодирование обычно не является эффективным использованием времени архитектора. Так что мне делать?
- Понимание бизнеса.
- Понимание систем, используемых для ведения бизнеса.
- Работа с бизнесом по ИТ-стратегии и тактике.
- Убедиться в том, что текущие проекты выполняются с долгосрочной точки зрения, где менеджер проекта концентрируется на краткосрочной перспективе.
Так как же архитектору поддерживать связь с реальностью? Я думаю о регулярных встречах и обходах, просто общаюсь с людьми на всех уровнях и смазываю колеса общения.
Я пришел к выводу, что чаще всего "детали реализации" не являются деталями (в том смысле, что многие проблемы возникают, когда вы рассматриваете некоторые конкретные проблемы реализации как простые детали, которые можно игнорировать как мелочи с "архитектурной" точки зрения).)
Архитектор приложения должен уметь определять архитектуру приложения, проектировать приложение, реализовывать шаблоны и обучать других программированию. Если вы не можете делать такие вещи, то вы не являетесь архитектором приложений.
Поскольку все здесь - кодеры, фаворитами должен быть ад, да, и вы не получите от меня никаких разногласий.
Но более точный ответ, на мой взгляд, является более правильным, потому что он надлежащим образом оценивает экспертизу предметной области. Люди, которые знают немного о программном обеспечении, но просто используют его, очень ценны.
То, как распределены архитектурные роли, зависит от размера и характера организации.
Если бы у меня было все по-своему, я бы дал клиенту роль Story Architect, если бы он писал хорошие, полезные, подробные истории и сценарии использования.
Иногда они должны кодировать. Например, когда в команде только один человек.
На мой взгляд, они могут кодировать, если хотят, но не должны терять общую картину. Не стоит менять проектируемые конструкции каждый день.
Будет ли просто написание интерфейсов считаться кодом? Если это так, то это минимум, который я бы ожидал от архитектора, в то время как в других случаях это может быть гораздо больше кода от них, таких как классы с заглушками для методов.
На риск отойти от темы...
В крупномасштабном приложении для архитектора может быть невозможным оставаться в курсе написанного кода. Кроме того, он не сможет написать код из-за других важных обязанностей. Сказав это, я бы порекомендовал, чтобы архитектор не потерял общую картину о разрабатываемой кодовой базе. Это может быть достигнуто путем мониторинга кодовой базы на предмет охвата кода, показателей качества кода, статического анализа кода и т. Д. Он должен регулярно оценивать качество кода с использованием упомянутых критериев. Здесь может помочь практика "непрерывной интеграции".
Архитектура является высокоуровневой ролью и не должна беспокоиться о реализации> подробности
Код это дизайн. Представьте себе архитектора, который проектирует красивые здания, но отказывается вдаваться в детали реализации, такие как расположение аварийных выходов, сантехника, электричество, лифты или строительные юридические вопросы.
* Coding is a detailed oriented, heads-down funtion which is at oddsс управлением рисками, широкий взгляд на природу архитектуры
Когда вы кодируете, сначала сосредоточьтесь на деталях. Затем вы рефакторинг с более широкой направленностью.
Архитектура - это лидерство. Сложно вести сзади
Фронт битвы при разработке программного обеспечения - это кодирование. Может быть менеджер по продукту или менеджер проекта не кодирует. Но архитектор должен это сделать. Может быть, ему стоит потратить больше времени на рефакторинг, показывающий, насколько хорошим может быть код. Таким образом, он приводит пример.
Вы спрашиваете об этом на сайте кодирования. Вы получите всех, кто падает на сторону "да".
Моя точка зрения - да, но достаточно, чтобы не отставать от меняющихся потребностей, не более
Архитектура является основным навыком для разработчиков программного обеспечения. Может быть несколько редких случаев, когда для архитектора имеет смысл не кодировать, но я не могу вспомнить, чтобы когда-либо сталкивался с такими случаями в моем собственном опыте.
Архитектор должен либо кодировать проект, либо, по крайней мере, быть полностью способным писать код проекта. Вторая часть этого означает, что они должны быть в состоянии кодировать, используя инструменты и методы, используемые остальной частью команды. (Без продолжения написания кода эти навыки должны быть очень трудными.)
Наконец, когда архитекторы несут ответственность за выбор инструментов и методов, которые будут использоваться другими, они не могут сделать такой выбор хорошо, фактически не используя предложенные инструменты. В этом сценарии некодирующий архитектор быстро вырождается в заостренного босса с кучей брошюр на столе.
Интересно, почему никто не упомянул обзоры кода или парное программирование, которое может заменить кодирование.
Я трачу гораздо больше времени на чтение кода и решение проблем с коллегами, чем на программирование. Это дает мне почти такое же понимание кода, его структуры и сложности, как и его написание, и требует гораздо меньше времени. Когда я пишу код, я делаю это для развлечения или для изучения новых технологий (это единственное место, где я нашел кодирование полезным).
Этот стандартный ответ разработчиков заключается в том, что архитектор должен также писать код. Но это своего рода разработчик, который ставит технологии на первое место. Но я склонен не соглашаться. Да, полезно иметь некоторые навыки программирования, чтобы иметь возможность просматривать код.
Но единственное, что делает Архитектор, - это объединяет бизнес-требования с реализацией. И в нашем случае код. Если у вас серьезно сложная система, вы не можете одновременно программировать и создавать архитектуру, потому что вы работаете на слишком многих разных уровнях абстракции.
Вместо этого вы должны быть в состоянии положиться на разработчиков. Они должны быть в состоянии описать аспекты реализации и их соответствие бизнес-требованиям, которые вы им указали. То, что технология выбрана, является решением Архитектора, но чтобы прийти к такому решению, он должен провести исследование или использовать прошлый опыт. Это не значит, что он не общается с разработчиками и не позволяет им исследовать конкретную технологию, чтобы увидеть, действительно ли работает архитектура.