Что вы должны принести на стол в качестве архитектора программного обеспечения? [закрыто]

Было много вопросов с хорошими ответами о роли Software Architect (SA) в StackOverflow и Programmers SE . Я пытаюсь задать немного более сфокусированный вопрос, чем те. Само определение SA является широким, поэтому ради этого вопроса давайте определим SA следующим образом:

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

Другими словами, я не говорю о управленческом отдыхе и жилете в типах SA (гребнеобразных слов). Если бы я занимал какую-либо позицию SA, я бы не хотел быть в стороне от кодирования. Я мог бы пожертвовать временем, чтобы пообщаться с клиентами, бизнес-аналитиками и т. Д., Но я все еще технически вовлечен и не просто осведомлен о том, что происходит во время встреч.

Имея в виду эти моменты, что SA должен принести на стол? Должны ли они прийти с менталитетом «изложить закон» (так сказать) и навязать использование определенных инструментов, чтобы соответствовать «их пути», т. Е. Руководящих принципов кодирования, контроля версий, шаблонов, документации UML и т. Д.? Или они должны указать начальное направление и стратегию, затем отложить назад и прыгнуть по мере необходимости, чтобы исправить направление корабля?

В зависимости от организации это может не сработать. SA, который полагается на TFS для обеспечения всего, может изо всех сил пытаться реализовать свой план у работодателя, который использует только StarTeam. Точно так же SA должен быть гибким в зависимости от стадии проекта. Если это новый проект, у них есть больше вариантов, тогда как у существующих проектов их может быть меньше.

Вот несколько историй SA, с которыми я столкнулся как способ поделиться своим опытом в надежде, что ответы на мои вопросы также могут пролить некоторый свет на эти проблемы:

• Я работал с SA, который проверял код буквально на каждой строчке кода команды. SA сделает это не только для нашего проекта, но и для других проектов в организации (представьте, сколько времени на это потрачено). Сначала было полезно применять определенные стандарты, но позже это стало наносить вред. FxCop был тем, как SA будет находить проблемы. Не поймите меня неправильно, это был хороший способ научить начинающих разработчиков и заставить их задуматься о последствиях выбранного ими подхода, но для старших разработчиков это было несколько драконовским.

• Один конкретный SA был против использования определенной библиотеки, утверждая, что это было медленно. Это заставило нас написать тонны кода, чтобы добиться чего-то другого, в то время как другая библиотека сэкономила бы нам много времени. Перенесемся в последний месяц проекта, и клиенты жаловались на производительность. Единственное решение состояло в том, чтобы изменить определенные функциональные возможности, чтобы использовать первоначально игнорируемый подход, несмотря на ранние предупреждения от разработчиков. К этому моменту большая часть кода была выброшена и не использовалась повторно, что приводило к сверхурочной работе и стрессу. К сожалению, оценки, использованные для проекта, были основаны на старом подходе, который мой проект запрещал использовать, поэтому он не был подходящим индикатором для оценки. Я бы услышал, как премьер-министр сказал: «Мы сделали это раньше»

• SA, который будет обеспечивать использование DTO, DO, BO, уровней обслуживания и т. Д. Для всех проектов. Новым разработчикам приходилось изучать эту архитектуру и строго соблюдаемые правила использования SA. Исключения из правил использования были сделаны, когда было абсолютно трудно следовать руководящим принципам. СА был основан на их подходе. Классы для DTO и всех операций CRUD были сгенерированы с помощью CodeSmith, а схемы баз данных были еще одним подобным шариком воска. Однако, использовав эту настройку везде, SA не был открыт для новых технологий, таких как LINQ to SQL или Entity Framework.

Я не использую этот пост в качестве платформы для вентиляции. В моем опыте с историями SA, упомянутыми выше, были положительные и отрицательные стороны. Мои вопросы сводятся к:

1. Что SA должен принести на стол?
2. Как они могут найти баланс в принятии решений?
3. Нужно ли подходить к работе SA (как определено ранее) с менталитетом, что они должны соблюдать определенные основные правила?
4. Что-нибудь еще, чтобы рассмотреть?

Благодарность! Я уверен, что эти рабочие задания легко распространяются на людей, которые являются старшими разработчиками или техническими руководителями, поэтому не стесняйтесь отвечать и на этом посту.

Системный архитектор должен:

1. Укажите архитектуру высокого уровня
2. Участвуйте в обзорах кода
3. Одобрить используемые технологии
4. Помогать разработчикам в их усилиях по написанию кода
5. Поддерживать и контролировать график развития
6. Создание SA-артефактов, таких как диаграммы UML, диаграммы Ганта и тому подобное.

SA должны знать, как кодировать, и должны участвовать в некоторых работах по кодированию, если можно так выразиться. Это поддерживает их связь с гештальтом разработки. Как однажды сказал дядя Боб Мартин , Архитектор должен сам выполнить часть кодирования, чтобы он мог видеть боль, которую он причиняет другим своими проектами.

У SA должно быть последнее слово во всех решениях дизайна, технологии и стиля кодирования. Но, как и все менеджеры, работа СА заключается в том, чтобы расчистить путь для своих людей, чтобы они могли быть продуктивными. По большей части это означает, что разработчики на своем уровне решают, как решать проблемы. Это означает, что SA не позволяет заостренным боссам попадать в кабины разработчиков. И это означает, что SA вносит свой вклад, чтобы помочь, по мере необходимости.

Как и все люди, SA могут и делают ошибки. Хорошие учатся на этих ошибках и становятся лучшими SA.

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

Для меня самые большие проблемы, которые я видел:

• слепая приверженность процессу ради процесса
• слепой уклон к технологии, прежде чем понять проблему
• создание и применение правил без веского обоснования
• rewrite from scratch склад ума

Лучшие «Архитекторы», с которыми я работал, подали к столу:

• Вопросы, которые привели к лучшему пониманию проблемы и потенциальных решений.
• Варианты дизайна / технологии и их компромиссы.
• Четкие и рациональные объяснения как осуждений, так и одобрений конструкций и технологий.

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

1 Что СА должен принести на стол?

• Толстая кожа
• Хорошие навыки ведения переговоров
• Хорошее понимание различных уровней программного обеспечения (от превосходного качества AJAX до низкоуровневого сетевого ввода-вывода). Вы не обязательно должны быть опытным специалистом, но вам нужно будет принять важные решения о том, какое программное обеспечение должно выполняться на каком (их) уровне (ах).
• Готовность запачкать руки в коде, дизайны белой бумаги просто не сокращают его.
• Поощрение мастерства программного обеспечения - будьте чирлидером для правильной работы, когда это возможно, и наилучшим образом с учетом ограничений в других случаях. Такие вещи, как контроль исходного кода, TDD, сборка и CI, кодирование DOJO, обзоры кода, хорошая система отслеживания ошибок и т. Д.

2 Как они могут найти баланс в принятии решений?

• Многое из этого зависит от вашей команды (команд) и их способности.
• Ваша среда (например, вас могут заставить использовать продукт конкретного поставщика)
• В целом, лучше не быть архитектором башни из слоновой кости, быть в курсе дела, быть частью команды - люди будут понимать ваши решения таким образом.

3 Следует ли подходить к работе SA (как определено ранее) с менталитетом, что они должны применять определенные основные правила?

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

Есть еще много, я думаю, что будут некоторые действительно хорошие ответы для этого.

1.Что SA должен принести на стол?

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

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

Что касается технологий: работайте с тем, что у вас есть, если компания использует StarTeam, то это то, что вы используете. Вступление в брак с каким-либо конкретным продуктом / технологией / процессом ничего не сделает для вас.

2. Как они могут найти баланс в принятии решений?

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

3. Нужно ли подходить к работе SA (как определено ранее) с менталитетом, что они должны соблюдать определенные основные правила?

Всегда. Если нет, то заключенные закончат убежище, открыто или скрыто. Решить эти основные правила, однако, можно через разговор с командой. Помните, что у любой команды не всегда могут быть те же члены, которые у нее есть сейчас, поэтому уступки небольшой группе из них могут помешать команде в будущем, когда они уйдут. Это включает в себя SA.

4.Что еще нужно рассмотреть?

• В отношении вашего второго примера: кажется, что команда проекта сформировала тесно связанную зависимость от внутренней подсистемы. Слабосвязанные фасады предназначены не только для стороннего кода. Создание абстракции для этой подсистемы могло бы упростить переход к использованию этой библиотеки в случае сбоя внутреннего решения. Это логичное решение для одного только архитектора программного обеспечения, но оно также является формой менеджера проекта с выражением озабоченности команды, и это должно было быть вдвойне очевидным решением.
• В отношении вашего третьего примера: неплохая идея - иметь известную архитектуру или процесс для производства программного обеспечения (хотя, по общему признанию, вы сказали «все проекты»). Это придерживается того, что работает. С учетом вышесказанного, должны быть возможности, где можно попробовать новые методы, чтобы увидеть, приносят ли они дополнительную ценность. Программное обеспечение, предназначенное только для дома, или проекты меньшего масштаба, в которых можно использовать эти технологии, являются идеальными местами. Имейте в виду, однако, что ответственность за разработку и убедительные демонстрации / аргументы в пользу принятия технологий лежит также на разработчике (ях). И нельзя ожидать, что SA будет знать каждую конкурирующую ORM и ее сильные и слабые стороны по сравнению с другими.