Мне приходится часто прорабатывать и принимать архитектурные решения, а также проводить их ревью. Сейчас я могу сказать, что существует несколько моментов, которые часто упускаются из вида. В этой статье предложено 5 советов по грамотному принятию технических решений, в том числе архитектурных.
Блог, который вы читаете, не затрагивает именно технических моментов, будь то выбор микросервисов или монолита, выбор Golang или Rust, а, скорее, предлагает несколько других, но не менее важных, аспектов, с которых стоит оценивать технические решения.
Совет № 1: Исходим из требований
Инженеры любят закапываться в технину, порой забывая о том, для чего это все делается. Из-за этого часты кейсы, при которых решение становится невалидным и задача попросту не решается.
Приведу один яркий пример: команде необходимо было разблокировать использование аутсорса на проекте. Для этого решили выделить часть кода в отдельный модуль. Однако команда так увлеклась архитектурой, что во время аудита, через несколько месяцев мы поняли, что команда идет совершенно не туда. Как результат - 2 квартала потрачены практически впустую.
Для решения этой проблемы в рамках проработки архитектуры существует этап валидации требований, который состоит из двух частей:
Совет № 2: Учитывайте стандарты компании
Сюда входит, в том числе, стандарты по использование языков программирование, баз данных, кешей и инфраструктуры. Будет очень странно, если в новом решений решили использовать Kafka, хотя вся компания сидит на RabbitMQ. Конечно, бывают случаи, когда новая технология действительно нужна, но тогда это решение должно быть аргументированным, но, к сожалению, часто это упускают из виду. Особенно часто я вижу здесь подход "берем модное-стильное-молодежное" без понимания, что это “модное-стильное-молодежное" потом надо поддерживать.
Совет № 3: Учитывайте команды
Архитектурное решение будет кем-то реализовываться, и странно выбирать Golang, в то время как в команде одни “питонисты”. И если про это еще более менее часто вспоминают, то реже вспоминают про системных администраторов и DBA: странно брать новую БД или API Gateway, опыта оперирования которыми у админов нет. Именно поэтому необходимо в рамках выработки решения коммуницировать со всеми, кто будет вовлечен как в реализацию, так и в поддержку нового решения.
Совет № 4: Документация важна
Зачастую происходит ситуация, когда никто в команде и/или компании не знает, как работает тот или иной кусок системы. А когда узнают, то не понимают, почему было сделано именно так. Именно поэтому необходимо документировать принятые решения, в том числе с использованием подхода Architecture Decision Record.
В сети существует достаточно много примеров того, как такие решения можно оформлять. В моей практике у нас был шаблон в Confluence, в котором использовался определенный лейбл: по нему мы собирали все решения и складывали на одной странице. Это помогало нам при принятии следующих решений, при расследовании инцидентов и онбординге новых сотрудников.
Совет № 5: Думайте о последствиях решения
Об этом задумываются крайне редко, но в результате изменения архитектуры мы не только решаем бизнес-задачу, но и получаем другие сайд-эффекты, например:
И это только одни из многих вариантов, наиболее распространенные.
Последствия являются важным критерием при выборе архитектурного решения, обращайте на них внимание.
Вывод
Приведенные топ-5 советов по разработке архитектурных решений помогут вам избежать некоторых распространенных ошибок и сделают процесс принятия решений более структурированным и эффективным. Помните, что архитектурные решения не бывают идеальными для всех ситуаций, поэтому всегда учитывайте контекст и специфику вашего проекта.
Счастливого кодинга и успешных архитектурных решений!
Блог, который вы читаете, не затрагивает именно технических моментов, будь то выбор микросервисов или монолита, выбор Golang или Rust, а, скорее, предлагает несколько других, но не менее важных, аспектов, с которых стоит оценивать технические решения.
Совет № 1: Исходим из требований
Инженеры любят закапываться в технину, порой забывая о том, для чего это все делается. Из-за этого часты кейсы, при которых решение становится невалидным и задача попросту не решается.
Приведу один яркий пример: команде необходимо было разблокировать использование аутсорса на проекте. Для этого решили выделить часть кода в отдельный модуль. Однако команда так увлеклась архитектурой, что во время аудита, через несколько месяцев мы поняли, что команда идет совершенно не туда. Как результат - 2 квартала потрачены практически впустую.
Для решения этой проблемы в рамках проработки архитектуры существует этап валидации требований, который состоит из двух частей:
- Каждому элементу новой архитектуры (каждая стрелочка, каждый прямоугольник) сопоставляется бизнес-требование, либо другой элемент. Если связей нет, то элемент считается не нужным.
- Каждому требованию сопоставляется элемент или набор элементов архитектуры. Таким образом, мы валидируем, учтены ли все требования. Если элемент (или набор) не найден, значит требование выполнено.
Совет № 2: Учитывайте стандарты компании
Сюда входит, в том числе, стандарты по использование языков программирование, баз данных, кешей и инфраструктуры. Будет очень странно, если в новом решений решили использовать Kafka, хотя вся компания сидит на RabbitMQ. Конечно, бывают случаи, когда новая технология действительно нужна, но тогда это решение должно быть аргументированным, но, к сожалению, часто это упускают из виду. Особенно часто я вижу здесь подход "берем модное-стильное-молодежное" без понимания, что это “модное-стильное-молодежное" потом надо поддерживать.
Совет № 3: Учитывайте команды
Архитектурное решение будет кем-то реализовываться, и странно выбирать Golang, в то время как в команде одни “питонисты”. И если про это еще более менее часто вспоминают, то реже вспоминают про системных администраторов и DBA: странно брать новую БД или API Gateway, опыта оперирования которыми у админов нет. Именно поэтому необходимо в рамках выработки решения коммуницировать со всеми, кто будет вовлечен как в реализацию, так и в поддержку нового решения.
Совет № 4: Документация важна
Зачастую происходит ситуация, когда никто в команде и/или компании не знает, как работает тот или иной кусок системы. А когда узнают, то не понимают, почему было сделано именно так. Именно поэтому необходимо документировать принятые решения, в том числе с использованием подхода Architecture Decision Record.
В сети существует достаточно много примеров того, как такие решения можно оформлять. В моей практике у нас был шаблон в Confluence, в котором использовался определенный лейбл: по нему мы собирали все решения и складывали на одной странице. Это помогало нам при принятии следующих решений, при расследовании инцидентов и онбординге новых сотрудников.
Совет № 5: Думайте о последствиях решения
Об этом задумываются крайне редко, но в результате изменения архитектуры мы не только решаем бизнес-задачу, но и получаем другие сайд-эффекты, например:
- Увеличение:
- поддержки команды системных администраторов за счет поднятия новых инфраструктурных компонентов
- поддержки команды разработки за счет создания нового приложения
- риска инцидентов за счет добавления новых точек отказа
- регулярных расходов за счет покупки лицензий (например, на API Gateway).
- Изменение времени ответа, как в меньшую, так и в большую сторону
- Необходимость найма новых людей, как в команду разработки, так и в команду оперирования
И это только одни из многих вариантов, наиболее распространенные.
Последствия являются важным критерием при выборе архитектурного решения, обращайте на них внимание.
Вывод
Приведенные топ-5 советов по разработке архитектурных решений помогут вам избежать некоторых распространенных ошибок и сделают процесс принятия решений более структурированным и эффективным. Помните, что архитектурные решения не бывают идеальными для всех ситуаций, поэтому всегда учитывайте контекст и специфику вашего проекта.
Счастливого кодинга и успешных архитектурных решений!
