The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Архитектор программного обеспечения является ключевым человеком в любом программном проекте, независимо от его масштаба. Архитектор лично несет ответственность за технический результат всей команды. Хороший архитектор знает, что нужно сделать и как это будет сделано, как с точки зрения архитектуры, так и с точки зрения дизайна. Для воплощения этой идеи на практике архитектор использует два инструмента: ошибки и обзоры.
В Zerocracy мы не одобряем любое общение между разработчиками, если они не формально привязаны к тикетам или задачам, над которыми мы работаем. Подробнее об этом подходе можно прочитать в этой статье.
Тот же принцип применяется к архитектору. Мы не проводим встречи, стендапы, звонки в Skype, каналы IRC или какие-либо другие инструменты, где информация летает в воздухе и остается в наших головах. Вместо этого мы все записываем и говорим только тогда, когда нас явно просят и платят за это — в тикетах.
С учетом этого, можно задать разумный вопрос: как может архитектор программного обеспечения привести в жизнь свое техническое видение для команды, если он не может общаться с ней? Вот наш ответ: архитектор должен использовать баги.
Баг - это тикет, включающий в себя информацию о докладчике, проблеме и исполнителе, как объясняется в этом посте. Предположим, архитектор рассматривает существующее техническое решение и находит что-то, что противоречит его видению. Когда такое противоречие обнаружено, это хороший кандидат на баг. Иногда в коде просто не достаточно информации, и это также хороший кандидат на баг.
Таким образом, баги, сообщенные архитектором, служат каналами связи между ним и командой. Архитектор не объясняет, что нужно сделать, но просит команду исправить продукт так, как он считает правильным. Если исполнитель тикета, член команды, не согласен с таким подходом, начинается обсуждение прямо в тикете.
Иногда у архитектора возникают сомнения, и ему необходимо обсудить несколько возможных решений с командой или просто собрать мнения. Снова мы используем баги для этого. Но эти баги не сообщают о проблемах в исходном коде, а жалуются на неполную документацию. Например, предположим, архитектор не знает, какую базу данных использовать, MongoDB или Cassandra, и ему нужна больше информации о их плюсах и минусах. Баг будет звучать как “наша документация не содержит подробного сравнения существующих NoSQL баз данных; пожалуйста, исправьте это”. Тот, кому назначен этот тикет, выполнит сравнение и обновит документацию.
Баги - это активный инструмент для архитектора. С помощью сообщения багов архитектор влияет на проект и “диктует свою волю”.
В наших проектах каждый тикет реализуется в собственной ветке. После завершения реализации все тикеты проходят обязательный кодовый ревью. Другими словами, разработчики осуществляют обзор кода друг друга. Архитектор не участвует в этом процессе.
Но после завершения кодового ревью каждый тикет передается архитектору, и он должен дать окончательное “ОК”, прежде чем код попадет в ветку master через нашего бота для слияния Rultor.
Это возможность для контроля архитектора. Здесь он может предотвратить разрушение своей концепции. Если код, созданный разработчиком, нарушает принципы проектного дизайна или любую часть технической концепции, архитектор говорит “нет”, и ветка отклоняется.
Ревью являются реактивным инструментом для архитектора. Через строгое и некомпромиссное кодовое ревью архитектор пропагандирует свои принципы дизайна и архитектуры.
P.S. Вот как архитектор должен сообщать руководителю проекта: Три вещи, которые я ожидаю от архитектора программного обеспечения.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 10:30
