Когда вы пишете код, наверняка хотите, чтобы система, над которой вы работаете, была не просто «рабочей», а надёжной, гибкой и готовой к росту. Вы интуитивно чувствуете, что архитектура — это ключ, но сталкиваетесь с огромным количеством противоречивых мнений.
Этот хаос приводит к дорогим ошибкам: монолиты, превратившиеся в Big Ball of Mud, проекты, которые невозможно масштабировать, и команды, увязшие в техническом долге.
Давайте разберём популярные мифы и как обстоят дела на самом деле.
Миф №1: «настоящая» архитектура — это микросервисы
В чём заблуждение?
Многие разработчики и даже компании считают, что современный и «правильный» проект обязан быть на микросервисах. Монолит воспринимается как нечто устаревшее и постыдное. Команды бросаются резать систему на сервисы, даже не имея чётких для этого предпосылок.
Почему это опасно?
Преждевременное внедрение микросервисов — прямой путь к катастрофе. Вместо одного предсказуемого монолита вы получаете распределённый монолит — хаотичную систему, где сервисы тесно связаны, но при этом добавляются сетевые задержки, проблемы с консистентностью данных и экспоненциальный рост сложности в отладке и развёртывании. Поиск одной ошибки превращается в детективное расследование по логам 15 сервисов.
Как на самом деле?
Микросервисы — это не цель, а инструмент для решения конкретных проблем:
- Организационная масштабируемость: когда над продуктом работает множество независимых команд.
- Технологическая гетерогенность: когда для разных частей системы нужны разные стеки технологий.
- Изолированное развёртывание: когда критически важно обновлять части системы независимо друг от друга.
Золотое правило: начинайте с хорошо структурированного монолита. Выделите логические модули с чёткими границами. Когда (и если) какой-то из модулей потребует отдельного масштабирования или независимого цикла разработки, вы сможете отпилить его в микросервис с минимальными усилиями.
Миф №2: архитектура — это то, что мы делаем в самом начале
В чём заблуждение?
Этот миф родом из «водопадной» модели разработки. Архитектор в «башне из слоновой кости» рисует всеобъемлющие UML-диаграммы, создает толстый талмуд документации и передает его команде для реализации. После этого его работа якобы закончена.
Почему это опасно?
Такой подход (Big Design Upfront) почти никогда не работает. Требования меняются, бизнес-цели уточняются, а первоначальные предположения оказываются неверными. В итоге команда либо игнорирует мёртвую документацию, либо тратит месяцы на переделку системы, которая уже не соответствует реальности. Это прямой путь к срыву сроков и демотивации.
Как на самом деле?
Архитектура — это непрерывный процесс, а не однократное событие. Современный подход — это эволюционная архитектура. Мы принимаем важные, труднообратимые решения в начале, но оставляем пространство для изменений. Архитектор — это играющий тренер, а не чертёжник. Он работает вместе с командой, проверяет гипотезы через прототипы и постоянно адаптирует архитектуру под новые знания о продукте и домене.
Миф №3: в Agile нет времени на архитектуру
В чём заблуждение?
Многие agile-команды, увлекаясь двухнедельными спринтами и быстрой поставкой фич, полностью игнорируют архитектурные вопросы. Любые разговоры об инфраструктуре или рефакторинге откладываются на потом под предлогом «мы же гибкие».
Почему это опасно?
Agile — это про гибкость, а не про хаос. Без продуманной архитектурной основы система быстро деградирует. Каждый новый спринт добавляет сложности, технический долг растет как снежный ком, и в итоге скорость разработки падает до нуля. Команда тратит всё время на борьбу с багами и костылями, а не на создание ценности для бизнеса. «Гибкость» превращается в паралич.
Как на самом деле?
Agile и архитектура — не враги, а союзники. Задача в том, чтобы найти баланс между быстрой поставкой ценности и поддержанием технического здоровья системы. Для этого существуют специальные практики:
- Архитектурное русло (Architectural Runway): команда целенаправленно выделяет часть времени в спринтах на создание и развитие технической базы (компонентов, API, инфраструктуры), которая потребуется для будущих фич.
- Архитектурные истории (Enabler Stories): задачи по рефакторингу, исследованию новых технологий или погашению техдолга оформляются как полноценные задачи в бэклоге и получают свой приоритет.
Миф №4: хорошая архитектура — это использование самых новых технологий
В чем заблуждение?
«Мы будем использовать Kubernetes, Istio, gRPC и последнюю версию фреймворка X, потому что это круто и современно». Такой подход, известный как Resume-Driven Development (RDD), ставит технологию впереди решаемой проблемы.
Почему это опасно?
Новые, хайповые технологии часто незрелы, имеют мало документации и небольшое комьюнити. Команда тратит бесценное время на изучение их особенностей и борьбу с «детскими болезнями» вместо того, чтобы решать бизнес-задачу. Сложность системы искусственно завышается, а реальной выгоды это не приносит.
Как на самом деле?
Выбор технологии — это следствие архитектурных требований, а не их причина. Сначала определите нефункциональные требования: какая нужна производительность, надёжность, масштабируемость? Каковы ограничения по бюджету и экспертизе команды? И только потом подбирайте самый скучный и проверенный инструмент, который справится с задачей. Лучшая технология — та, которую ваша команда знает и которая решает проблему с минимальными издержками.
Миф №5: архитектор — это самый старший программист, который больше не пишет код
В чем заблуждение?
Распространённое мнение, что архитектор — это почётная должность для ветерана, который теперь только рисует диаграммы и указывает другим, что делать. Он витает в облаках абстракций и давно не прикасался к коду.
Почему это опасно?
Архитектор, оторванный от кода и реальных проблем команды, принимает нежизнеспособные решения. Его красивые схемы могут быть неэффективными или вовсе нереализуемыми на практике. Это порождает конфликт между теоретиком-архитектором и практиками-разработчиками, что убивает любую инициативу и замедляет проект.
Как на самом деле?
Эффективный архитектор — это технический лидер, который остается «играющим тренером». Он может не писать код каждый день, но он обязан:
- Регулярно участвовать в код-ревью
- Помогать в решении самых сложных технических проблем
- Создавать прототипы и proof-of-concept для проверки архитектурных гипотез
- Быть наставником для других разработчиков, объясняя почему и как устроена система.
Стать эффективным архитектором и научиться создавать поддерживаемые системы и организовывать код можно на курсе Слёрма «Архитектура приложений: от идеи до архитектурного решения». Вы научитесь смотреть на систему, как архитектор, рефакторить код, проектировать ПО, учитывая изменчивость ИТ-систем, строить UML-диаграммы и много чему ещё. Новый поток стартует 6 октября. Подробная программа и тарифы — по ссылке.