The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Более 25 лет назад, в 1992 году, на воркшопе OOPSLA в Ванкувере Кент Бек, в ответ на вопрос “Что такое архитектор?”, согласно Филиппу Круктену, сказал, что это “новое пафосное звание, которое программисты требуют указывать на своих визитках, чтобы оправдать свои щедрые вознаграждения.” С тех пор мало что изменилось. Между умным программистом и архитектором проекта есть большая разница. Вот список качеств, которые, я считаю, должны быть у хорошего архитектора.
Отказ от ответственности: Хотя я ни разу не видел женщин-архитекторов программного обеспечения в своей жизни, я должен сказать для своих левых/феминистических читателей, что в этом блоге я предполагаю, что архитектор - это мужчина только ради удобства речи. Нет никакого намерения оскорбить кого-либо.
Программисты приходят и уходят. Как я уже неоднократно упоминал, они эгоистичны и ориентированы на личную выгоду. Они меняют проекты, работают над несколькими проектами одновременно, у них нет личной привязанности к какому-либо коду. Они беспокоятся только о своих индивидуальных задачах и ветках разработки. Ветка слилась? Все ставки сняты. Профессиональные разработчики “многоженцы” и нелояльны.
Архитектор, однако, - это другое существо. Он остается с проектом даже после исчерпания финансовых средств, ухода последнего программиста и доказательства того, что архитектура - это полный беспорядок, который не может обрабатывать даже долю трафика, для которого он предназначался. Архитектор остается и говорит: “Не беспокойтесь, мы справимся, несмотря ни на что!” Как найти такого человека и как его мотивировать - это другие вопросы, может быть, для другого блога.
Он дисциплинирован.
Шаблоны проектирования, качество кода, статический анализ, модульное тестирование, высокая производительность, надежность, безопасность и даже поддерживаемость - все это очень важные вещи, о которых нужно беспокоиться. Однако хороший архитектор знает, что все это может быть решено и достигнуто программистами, если они будут правильно наняты, мотивированы, организованы и контролируются. Как нанимать, мотивировать, организовывать и контролировать их - об этом беспокоится хороший архитектор.
Он знает, что процесс важнее, чем люди.
Однако это не то, о чем думают большинство экспертов по программному обеспечению. Например, согласно статье Элистера Кокберна Agile Software Development: The People Factor, опубликованной в журнале IEEE Computer в 2001 году: “Если участники проекта достаточно хороши, они могут использовать практически любой процесс и выполнить свое задание. Если они недостаточно хороши, ни один процесс не исправит их неполноценность - ‘люди важнее процесса’ - так можно выразить это”. Это может быть приемлемо для программиста, но не для архитектора.
Архитектор ставит дисциплину превыше всего, постоянно придумывая новые правила и их соблюдая. Более того, он не только заставляет других подчиняться, но и сам следует правилам. Вот, например, правила, которые нужно соблюдать:
Каждая идея начинается с тикета;
Ветка master доступна только для чтения.
Статический анализ обязателен;
Никаких синглтонов, геттеров/сеттеров и так далее;
Модульное тестирование обязательно для всех новых изменений.
Без неформальных обсуждений вне тикетов.
Каждый проект имеет свой набор правил. Список выше является подмножеством того, что у нас есть на наших проектах в Zerocracy. Хороший архитектор думает о правилах в первую очередь, а о архитектуре - во вторую.
Я полностью согласен с Леном Бассом, который сказал в своей книге Software Architecture in Practice, что “архитектура должна быть продуктом одного архитектора”. Однако вопрос заключается в том, как именно архитектор создаст продукт: либо в одиночном режиме, принимая все технические решения в одиночку, либо позволяя команде вносить свой вклад организованным и дисциплинированным образом. Первый вариант прост, но менее эффективен, второй гораздо сложнее, но приводит к более сильным решениям и лучшей командной синергии (ненавижу это слово, но здесь оно подходит).
Мэттью Макбрайд сказал в своей статье “The Software Architect”, опубликованной в CACM в 2007 году, что “Без тщательного руководства со стороны архитектора программного обеспечения проекты и попытки решений обычно разрушаются из-за неуправляемой сложности.” Здесь важно подчеркнуть слово “тщательный”.
Что имеется в виду под силой в этом контексте? Способность провести два дня в офисе, питаясь только пиццей и колой? Способность умножать шестизначные числа в памяти? Способность запомнить цель и дизайн всех классов и методов? Способность продержаться на встрече с инвесторами три часа, даже один раз не заглядывая на Facebook? Вряд ли.
Сила архитектора заключается в способности сказать “Нет”, когда это трудно сделать. Например:
“Нет, мы не будем внедрять эту функцию.”
“Нет, вам пока не полагается повышение.”
“Нет, ваш код не так хорош, как мы ожидаем.”
Нет, данная сборка недостаточно стабильна для выпуска.
“Нет, в этом месяце ты не уйдешь в отпуск.”
Есть еще много других случаев, когда “Нет” может легко превратить архитектора в ненавистную фигуру, но вот его работа - быть плохим парнем. Вот почему ему нужно быть сильным - спокойно справляться со всем этим и продолжать вести проект вперед, к своим четко определенным техническим целям.
Абстрактное мышление является очень важным положительным качеством архитектора. Программисты могут лишаться этого, так как они в основном сосредоточены на своих отдельных задачах. Архитектор должен мыслить глобально и видеть продукт как единое целое. Детали менее важны. Он должен полагаться на своих специалистов, когда речь заходит о деталях.
Программное обеспечение является продуктом людей. Неважно, насколько велик архитектор, если он не может найти правильных людей для реализации своих идей и поиска новых идей, он обречен на провал. Ключевое качество архитектора - это умение работать с людьми: набирать, мотивировать и контролировать их результаты. Социальные навыки - это то, что нужно архитектору, чтобы быть успешным в этом, особенно при поиске новых программистов и вовлечении их в проект. Что это конкретно означает? Вот несколько примеров:
Длинный список предыдущих проектов и команд;
Активное участие в профессиональных группах;
Публикация в блогосфере.
Другими словами, хороший архитектор - это тот, у которого вокруг него есть большая группа последователей и сторонников. Я упомянул об этом в моей последней презентации Сколько вы стоите? на конференции JEEConf 2017.
Хороший архитектор говорит много раз в день: “Это моя вина.” Если у архитектора нет привычки говорить это часто, значит, он не хороший архитектор. Он просто программист, который боится ответственности и власти.
Золотое правило хорошего менеджера: “Успех - ваш, ошибки - мои.” Такое отношение хороший архитектор должен выражать своей команде. Когда они побеждают, он всегда найдет способ отпраздновать и вознаградить их. Когда они терпят неудачу, он возьмет полную ответственность за нее. Потому что это его команда, он их нашел, мотивировал, контролировал и недостаточно наказал. Вот почему они потерпели неудачу. Прежде всего, это его вина.
Что он будет делать с этой ошибкой - отдельный вопрос. Может быть, он обучит и наставит кого-то, может быть, он будет более активно соблюдать некоторые правила, может быть, он даже отдаст кому-то свою визитку. Это зависит от архитектора. Но для внешнего мира он всегда будет виновным, и команда должна знать это. Если они знают это, они сделают все возможное, чтобы не подвести архитектора.
“Простота - это большая добродетель”, сказал Эдсгер Дейкстра в 1984 году. Для программиста это добродетель, для архитектора - навык выживания. Архитектор, который не может объяснить свои идеи простыми словами, легко понятными другим программистам, не является архитектором. Неважно насколько он умный, насколько блестящи его идеи. Если они не могут быть представлены в простой форме, они ничего не стоят.
“Если я не понимаю тебя, это твоя вина”, сказал Егор Бугаенко в 2015 году. Хороший архитектор помнит об этом.
Антони Лэнгсуорт в своей статье Должны ли архитекторы программного обеспечения писать код? выступает в защиту архитекторов, которые пишут код, и особенно утверждает, что “понимание кода позволяет архитектору принимать более эффективные решения, а не полагаться на то, какой разработчик более убедителен”. Действительно, архитектор, который способен только говорить и рисовать, является слабым архитектором, который рано или поздно подведет команду и проект.
В том, насколько много кода должен писать архитектор, зависит от возраста проекта. Когда проект молодой и находится в стадии прототипирования, архитектор создает большую часть кода. Затем, позднее, когда продукт созревает, архитектор отходит в сторону и в основном проверяет вклад программистов. В конечном итоге, когда проект переходит в фазу поддержки, архитектор может покинуть проект и передать свои обязанности одному из программистов.
Он амбициозен.
Архитектор хочет получить что-то, помимо денег. Он хочет быть самым умным человеком в комнате, он хочет решать сложные задачи, которые никто другой не смог решить раньше, он хочет спасать мир. Он хочет, чтобы все это было оценено и вознаграждено. Он хочет быть номером один. В большинстве случаев он проваливается в этом. Но он всегда поднимается на ноги и пытается снова. Ищите человека с амбициями, если вы хотите нанять архитектора, а не еще одного программиста.
Майкл Килинг в своей недавней книге Design It!: From Programmer to Software Architect (стоит прочитать) говорит: “В некоторых командах архитектор - это официальная роль в команде. В других командах нет явной роли, и обязанности архитектора делятся между членами команды. Некоторые команды говорят, что у них нет архитектора, но если присмотреться внимательно, кто-то выполняет обязанности архитектора, даже не осознавая этого. Если вашей команде не требуется архитектор, поздравляю, вы получили эту работу!”
По мнению Майкла, должность архитектора редко дается кому-то по собственному желанию. Вместо этого архитектор должен бороться за нее и требовать ее. Иногда даже говорить прямо: “Я хочу быть архитектором!”
Важно, чтобы это не звучало как “Я хочу спроектировать это.” Это был бы голос программиста, а не архитектора. Архитектор хочет быть человеком власти, а не просто умным техническим инженером. Так что это гораздо больше о титуле для него, а не только о его фактических обязанностях.
Он дорогой.
Да, вопрос о деньгах снова. Хороший архитектор стоит дорого. Если он не стоит дорого, значит, он не хороший архитектор.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 14:19
