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-каналы или любые другие инструменты, где информация летает в воздухе и остается в наших головах. Вместо этого, мы записываем все на бумагу и говорим только в том случае, если нас явно просят и оплачивают—в рамках задач.
Bugs
С учетом этого, может возникнуть разумный вопрос: как программный архитектор может обеспечить реализацию своего технического видения командой, если он не может общаться с ней? Вот наш ответ: архитектор должен использовать баги.
Баг - это тикет, в котором есть автор, проблема и исполнитель, как объясняется в этом посте. Представим, что архитектор рассматривает существующее техническое решение и находит что-то, что противоречит его видению. Когда такое противоречие обнаружено, это хороший кандидат на баг. Иногда в коде просто недостаточно информации, и это также хороший кандидат на баг.
Таким образом, баги, сообщаемые архитектором, служат каналами связи между ним и командой. Архитектор не объясняет, что нужно сделать, но просит команду исправить продукт так, как он считает правильным. Если исполнитель тикета, член команды, не согласен с таким подходом, обсуждение начинается прямо в тикете.
Иногда у архитектора возникают сомнения и ему нужно обсудить несколько возможных решений с командой или просто собрать мнения. Опять же, мы используем баги для этого. Но эти баги не сообщают о проблемах в исходном коде; вместо этого они жалуются на неполную документацию. Например, предположим, что архитектор не знает, какую базу данных использовать, MongoDB или Cassandra, и ему нужна больше информации о их преимуществах и недостатках. Баг будет звучать как “наша проектная документация не содержит подробного сравнения существующих NoSQL баз данных; пожалуйста, исправьте это”. Тот, кому будет назначен этот тикет, выполнит сравнение и обновит документацию.
Баги - это проактивный инструмент для архитектора. Сообщая о багах, архитектор влияет на проект и “диктует свою волю”.
Reviews
В наших проектах каждый тикет реализуется в своей собственной ветке. Когда реализация завершена, все тикеты проходят обязательный кодовый ревью со стороны коллег. Другими словами, разработчики проверяют код друг друга. Архитектор не участвует в этом процессе.
Но после завершения ревью со стороны коллег каждый тикет отправляется архитектору, и только после его окончательного одобрения код попадает в основную ветку “master” через нашего робота-соединителя Rultor.
Это возможность для контроля со стороны архитектора. Здесь он может предотвратить разрушение своей видения. Если код, созданный разработчиком, нарушает принципы проектного дизайна или любую часть общей технической идеи, архитектор говорит “Нет”, и ветка отклоняется.
Ревью - это реактивный инструмент для архитектора. Через строгое и некомпромиссное кодовое ревью архитектор навязывает свои принципы дизайна и архитектуры.
P.S. Вот как архитектор должен докладывать руководителю проекта: Три вещи, которые я ожидаю от программного архитектора.
Translated by ChatGPT gpt-3.5-turbo/36 on 2023-09-30 at 05:16
