The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Я уже объяснил, как я понимаю роль и обязанности архитектора программного обеспечения. Но один вопрос до сих пор остается без ответа, и он часто становится проблемой в наших проектах: что делает архитектор программного обеспечения, когда спонсор проекта не нравятся его технические решения? Архитектор реализует что-то определенным образом, а спонсор (или его представитель) говорит, что это не совсем так, как должно работать. Что дальше?
В наших проектах владелец продукта (PO) обычно является представителем спонсора проекта (платящего заказчика). Поскольку все наши проекты являются достаточно сложными пакетами программного обеспечения на языке Java, PO являются очень техническими людьми. Они являются программистами или ранее были программистами. Они понимают код, который мы пишем, и хотят, чтобы их мнение было учтено и уважено.
И я не говорю о глупых владельцах продукта - эти ребята - это отдельная история. Я говорю о вполне разумном владельце продукта с собственным техническим мнением, которое нужно услышать.
Вот практический пример. На прошлой неделе я начинал проект. Я был архитектором. Это был модуль на языке Java для сервера. Я решил использовать Maven в качестве системы автоматизации сборки.
Я создал некоторые начальные файлы, настроил pom.xml, кратко объяснил структуру проекта в README.md и отправил запрос на слияние (pull request). Крис, владелец продукта, проверил его и спросил: “Почему не Gradle?”
Это был разумный вопрос, верно? Gradle - это другая популярная система автоматизации сборки, которую я мог использовать, но не использовал. Вопрос в том, почему. Это был довольно невинный вопрос, и я объяснил ответ прямо там, в своем комментарии к запросу на слияние. Я сказал, что Maven более подходит для этого проекта, потому что … и так далее.
Но Крис возразил. Он все еще думал, что Gradle является лучшим выбором. У него были свои причины. Между тем я пытался убедить его в своей точке зрения. Я попытался несколько раз, а потом понял, что делаю что-то не так. Это не должно работать так.
Архитектор программного обеспечения не должен убеждать владельца продукта, заказчика или кого-либо еще. Вместо этого архитектор должен принимать свои решения и нести ответственность за полный успех или неудачу продукта, как я уже объяснял.
Есть простая причина для этого. Любая попытка убедить кого-либо вызывает возможность “утечки ответственности”. Что, если мне не удастся убедить? Я должен буду изменить свой план и использовать Gradle, верно? Что, если у продукта возникнут проблемы из-за этого решения? Я буду стараться обвинить Криса в этом, верно? Я больше не могу быть полностью ответственным за продукт, потому что меня “принудили” принять хотя бы одно решение.
Не поймите меня неправильно; хороший архитектор должен собирать разные мнения перед принятием собственного решения. Но сбор мнения Криса выглядел бы совсем иначе. Я бы спросил его сначала, что он думает о Maven и Gradle. Он бы сказал мне, что он не любит Maven из-за этого и того. И я бы учел это. Или, может быть, и нет. Но мое решение все равно осталось бы моим, принятым мной, без внешнего давления. И Крис все равно мог бы обвинить меня в любых негативных последствиях этого решения.
Но что должен делать Крис, если ему действительно не нравится мое решение? Ведь это его деньги и его продукт, верно? Ему важно. И он не хочет иметь Maven в своем продукте. Что он делает? Как он может повлиять на процесс принятия моих решений?
Это легко. В каждом программном проекте есть два документа. Первый - это требования, а второй - архитектура. Крис должен использовать оба документа, чтобы исправить меня и указать мне правильное направление. Вот как.
Во-первых, если он действительно не хочет использовать Maven, он должен внести изменения в документ с требованиями. Он должен добавить что-то вроде “система сборки должна быть Gradle, потому что …” Или даже без части “потому что”. Это зависит от него. В этом случае мне придется принять это во внимание, и я сделаю это. Я знаю, что мои проектные решения определяются требованиями. И не потому, что Крис убедил меня или я не смог его убедить, а потому что именно так гласит документ.
Во-вторых, если он не совсем уверен, что Gradle - правильный выбор, и просто хочет, чтобы я отнесся серьезнее к своим решениям, он должен пожаловаться (подав запрос на ошибку) на качество моего документа по архитектуре. Он должен сказать: выбор Maven не объяснен должным образом. Тогда я пересмотрю свое решение и либо изменю его, либо объясню лучше. Но снова я сделаю это не для того, чтобы угодить Крису, а чтобы исправить сообщенную ошибку.
Подводя итог, архитектор должен быть абсолютным техническим диктатором во время проекта и не должен убеждать никого. Если это не так, весь проект сталкивается с большими рисками, просто потому, что ответственность будет “утекать”.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-22 at 10:13
