The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Вы, вероятно, знаете, что я думаю о роли архитектора в программном проекте - это роль диктатора, который принимает все технические решения и несет полную ответственность за конечный результат. Я писал об этом и даже выступал с докладом Кто такой программный архитектор? на конференции BuildStuff в 2016 году. Однако, очевидный вопрос, который вы можете задать, следующий: что происходит, если архитектор ошибается? Значит ли это, что весь проект находится под угрозой провала? И не лучше ли сделать всю команду ответственной за результат, вместо того, чтобы иметь одну точку отказа?
Вопрос, действительно, очевиден. Диктатура - отличная модель управления, при условии, что диктатор умный. Это означает, прежде всего, иметь способность 1) анализировать реальность, 2) собирать все доступные различные мнения и 3) найти наилучший вариант, оставив личные эмоции в стороне. Сколько людей действительно могут это сделать? Никто Очень немногие.
Вероятно, большинство других будут злоупотреблять властью и превратятся в плохих диктаторов, которые не слушают никого, не обращают внимание на различные мнения и принимают технические решения на основе личных чувств. Сколько таких программных архитекторов существует? Все Многие.
Какое решение?
А что, если мы избавимся от диктатора с самого начала и позволим команде решить, какая архитектура будет правильной? А что, если мы заменим диктатуру демократией и позволим разработчикам программного обеспечения как-то голосовать, чтобы не было одной точки отказа? Они все будут ответственны за продукт, и когда он сломается - все будут виноваты. Верно?
“Качество и ответственность ничего не значат, пока они не приписываются лично”, - сказал я в своей книге Code Ahead. Групповая ответственность - это самая страшная ошибка, которую команда может совершить. Так что, нет! Ни голосования, ни демократии.
Представьте себе реальный проект, в котором архитектор принимает решение использовать MongoDB (NoSQL база данных) для сохранения платежей пользователей. Это сомнительное решение, поскольку традиционно реляционные базы данных считаются лучшим вариантом для финансовых данных. Однако мы знаем, что архитектор является диктатором, и нам не положено спорить. Мы не можем сказать архитектору, что его решение неправильное. Более того, мы не должны просить архитектора нас убедить. Решение принято. Оно сделано.
Мы можем напомнить, что единственный настоящий начальник архитектора - это требования. Архитектор может не слушать нас, разработчиков, клиентов, никого. Но требования являются непреложным начальником. Упоминалось ли в документе с требованиями что-то о выборе базы данных? Скорее всего, там об этом ничего не было. Так что архитектор сделал все правильно. В требованиях говорилось, что платежи должны сохраняться, и они сохраняются. Требования требовали, чтобы система обрабатывала до ста платежей в секунду, и она это делает. Так где же ошибка?
Ну, мы просто чувствуем, что выбор MongoDB был плохой идеей. Это просто интуитивное ощущение. Но, может быть, мы ошибаемся, а архитектор прав?
Чтобы сделать ситуацию более ясной и разрешить конфликт, нам нужно изменить документ с требованиями. Нам нужно сказать, что для этого конкретного решения требуется что-то еще. Допустим, мы добавим эту строку:
После утверждения данного условия требования архитектору придется улучшить документацию продукта. Будет проведен анализ MongoDB, PostgreSQL, Oracle и некоторых других баз данных. Будут определены некоторые критерии выбора, и архитектор предоставит некоторые данные, чтобы выбор MongoDB выглядел обоснованным.
После этого мнение архитектора станет цифровым артефактом, который может содержать дефекты. Сколько дефектов есть и насколько быстро мы их найдем, становится вопросом управления, который относительно легко решить. Нам просто нужно несколько дополнительных пар глаз, чтобы посмотреть на этот артефакт и сказать нам, что не так. Например, мы можем попросить кого-то из команды просмотреть анализ и сказать нам, что не так. Или мы можем нанять кого-то с рынка, кто очень дорог, но профессионал в области управления базами данных.
После сообщения о дефектах архитектор должен будет как-то их устранить. Либо анализ должен быть улучшен, либо решение должно быть изменено, если факты начинают говорить против него.
Чем ниже уровень риска в проекте, тем больше нужно пар глаз, чтобы рассмотреть принимаемые архитектором решения. Если качество очень важно или уровень профессионализма архитектора вызывает сомнения, нам нужно больше решений, которые будут задокументированы и чаще проверяться. Это простая игра с числами. Если архитектор полностью доверяется и проект не дорогой и краткосрочный - мы просто позволяем архитектору делать все, что он или она хочет.
С другой стороны, если архитектор начинающий, а проект очень важен для нас, мы должны требовать, чтобы большинство технических решений были задокументированы и проанализированы. Мы должны организовать как можно больше проверок этих документов, даже приглашая независимых экспертов.
Таким образом, подводя итоги, мы не должны ожидать, что архитектор будет экспертом, способным решить все проблемы. С другой стороны, мы не должны заменять архитектора демократическим голосованием. Оба подхода неверны. Правильный подход - контролировать качество принимаемых архитектором решений с помощью регулярных проверок.
Есть ли такие проверки в вашем проекте? Если нет, то почему?
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 13:43
