Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-19

1 Когда вы пишете код, наверняка хотите, чтобы система, над которой вы работаете, была не просто "рабочей", а надёжной, гибкой и готовой к росту. Вы интуитивно чувствуете, что архитектура - это ключ, но сталкиваетесь с огромным количеством противоречивых мнений.

2 Этот хаос приводит к дорогим ошибкам: монолиты, превратившиеся в Big Ball of Mud, проекты, которые невозможно масштабировать, и команды, увязшие в техническом долге.

3 Давайте разберём популярные мифы и как обстоят дела на самом деле.

4 Миф №1: "настоящая" архитектура - это микросервисы

5 В чём заблуждение?

6 Многие разработчики и даже компании считают, что современный и "правильный" проект обязан быть на микросервисах. Монолит воспринимается как нечто устаревшее и постыдное. Команды бросаются резать систему на сервисы, даже не имея чётких для этого предпосылок.

7 Почему это опасно?

8 Преждевременное внедрение микросервисов - прямой путь к катастрофе. Вместо одного предсказуемого монолита вы получаете распределённый монолит - хаотичную систему, где сервисы тесно связаны, но при этом добавляются сетевые задержки, проблемы с консистентностью данных и экспоненциальный рост сложности в отладке и развёртывании. Поиск одной ошибки превращается в детективное расследование по логам 15 сервисов.

9 Как на самом деле?

10 Микросервисы - это не цель, а инструмент для решения конкретных проблем:

11 <ol><li>Организационная масштабируемость: когда над продуктом работает множество независимых команд.</li>

12 <li>Технологическая гетерогенность: когда для разных частей системы нужны разные стеки технологий.</li>

13 <li>Изолированное развёртывание: когда критически важно обновлять части системы независимо друг от друга.</li>

14 </ol>Золотое правило: начинайте с хорошо структурированного монолита. Выделите логические модули с чёткими границами. Когда (и если) какой-то из модулей потребует отдельного масштабирования или независимого цикла разработки, вы сможете отпилить его в микросервис с минимальными усилиями.

15 Миф №2: архитектура - это то, что мы делаем в самом начале

16 В чём заблуждение?

17 Этот миф родом из "водопадной" модели разработки. Архитектор в "башне из слоновой кости" рисует всеобъемлющие UML-диаграммы, создает толстый талмуд документации и передает его команде для реализации. После этого его работа якобы закончена.

18 Почему это опасно?

19 Такой подход (Big Design Upfront) почти никогда не работает. Требования меняются, бизнес-цели уточняются, а первоначальные предположения оказываются неверными. В итоге команда либо игнорирует мёртвую документацию, либо тратит месяцы на переделку системы, которая уже не соответствует реальности. Это прямой путь к срыву сроков и демотивации.

20 Как на самом деле?

21 Архитектура - это непрерывный процесс, а не однократное событие. Современный подход - это эволюционная архитектура. Мы принимаем важные, труднообратимые решения в начале, но оставляем пространство для изменений. Архитектор - это играющий тренер, а не чертёжник. Он работает вместе с командой, проверяет гипотезы через прототипы и постоянно адаптирует архитектуру под новые знания о продукте и домене.

22 Миф №3: в Agile нет времени на архитектуру

23 В чём заблуждение?

24 Многие agile-команды, увлекаясь двухнедельными спринтами и быстрой поставкой фич, полностью игнорируют архитектурные вопросы. Любые разговоры об инфраструктуре или рефакторинге откладываются на потом под предлогом "мы же гибкие".

25 Почему это опасно?

26 Agile - это про гибкость, а не про хаос. Без продуманной архитектурной основы система быстро деградирует. Каждый новый спринт добавляет сложности, технический долг растет как снежный ком, и в итоге скорость разработки падает до нуля. Команда тратит всё время на борьбу с багами и костылями, а не на создание ценности для бизнеса. "Гибкость" превращается в паралич.

27 Как на самом деле?

28 Agile и архитектура - не враги, а союзники. Задача в том, чтобы найти баланс между быстрой поставкой ценности и поддержанием технического здоровья системы. Для этого существуют специальные практики:

29 <ul><li>Архитектурное русло (Architectural Runway): команда целенаправленно выделяет часть времени в спринтах на создание и развитие технической базы (компонентов, API, инфраструктуры), которая потребуется для будущих фич.</li>

30 <li>Архитектурные истории (Enabler Stories): задачи по рефакторингу, исследованию новых технологий или погашению техдолга оформляются как полноценные задачи в бэклоге и получают свой приоритет.</li>

31 </ul>Миф №4: хорошая архитектура - это использование самых новых технологий

32 В чем заблуждение?

33 "Мы будем использовать Kubernetes, Istio, gRPC и последнюю версию фреймворка X, потому что это круто и современно". Такой подход, известный как Resume-Driven Development (RDD), ставит технологию впереди решаемой проблемы.

34 Почему это опасно?

35 Новые, хайповые технологии часто незрелы, имеют мало документации и небольшое комьюнити. Команда тратит бесценное время на изучение их особенностей и борьбу с "детскими болезнями" вместо того, чтобы решать бизнес-задачу. Сложность системы искусственно завышается, а реальной выгоды это не приносит.

36 Как на самом деле?

37 Выбор технологии - это следствие архитектурных требований, а не их причина. Сначала определите нефункциональные требования: какая нужна производительность, надёжность, масштабируемость? Каковы ограничения по бюджету и экспертизе команды? И только потом подбирайте самый скучный и проверенный инструмент, который справится с задачей. Лучшая технология - та, которую ваша команда знает и которая решает проблему с минимальными издержками.

38 Миф №5: архитектор - это самый старший программист, который больше не пишет код

39 В чем заблуждение?

40 Распространённое мнение, что архитектор - это почётная должность для ветерана, который теперь только рисует диаграммы и указывает другим, что делать. Он витает в облаках абстракций и давно не прикасался к коду.

41 Почему это опасно?

42 Архитектор, оторванный от кода и реальных проблем команды, принимает нежизнеспособные решения. Его красивые схемы могут быть неэффективными или вовсе нереализуемыми на практике. Это порождает конфликт между теоретиком-архитектором и практиками-разработчиками, что убивает любую инициативу и замедляет проект.

43 Как на самом деле?

44 Эффективный архитектор - это технический лидер, который остается "играющим тренером". Он может не писать код каждый день, но он обязан:

45 <ul><li>Регулярно участвовать в код-ревью</li>

46 <li>Помогать в решении самых сложных технических проблем</li>

47 <li>Создавать прототипы и proof-of-concept для проверки архитектурных гипотез</li>

48 <li>Быть наставником для других разработчиков, объясняя почему и как устроена система.</li>

49 </ul>Стать эффективным архитектором и научиться создавать поддерживаемые системы и организовывать код можно на курсе Слёрма<a>"Архитектура приложений: от идеи до архитектурного решения".</a>Вы научитесь смотреть на систему, как архитектор, рефакторить код, проектировать ПО, учитывая изменчивость ИТ-систем, строить UML-диаграммы и много чему ещё. Новый поток стартует 6 октября. Подробная программа и тарифы -<a>по ссылке.</a>