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