Штош, все сроки просраны (как в жизни), но под вечер воскресенья попробую отдать хоть часть долга.
Итак...
Рассказывая в рамках конференций, личных бесед или рабочих обсуждений об архитектурных решениях, я часто говорю, что мы не обязаны принимать некоторые решения прямо сейчас. И что вообще
одна из функций современного архитектора — помогать откладывать принятие важных решений на попозже. Эту фразу я впитал в голову несколько лет назад, даже не помню, где (нейросети подсказывают, что это было в книгах у Форда и Ричардса, а также в каких-то книгах по Agile Software Development, которые я если и читал, то по диагонали).
Для многих людей, для которых
архитектура — это в первую очередь то, что дорого менять, поэтому надо это решить как можно раньше, это вызывает диссонанс. Более того, на одной из конференций меня даже как-то попросили «пояснить за базар» (цитата). И посмотрев топовую презентацию от Грегори Хоупа, автора
книги про паттерны интеграции и автора знаменитой метафоры про
«архитектурный лифт», я у себя в голове наконец-то вроде как смог сформировать такое пояснение. Попробую оформить.
Архитектурные решения действительно являются важными, потому что:
🔹 на них базируется множество других, более частных решений
🔹 они влияют на множество свойств и «разрезов» системы сразу
🔹 их принятие требует компромиссов (иначе говоря, «мы не сделаем всех счастливыми, поэтому сделаем всех одинаково несчастными»)
Примеры таких решений на моей практике: buy or build, выбор пути развития системы/подсистемы, выбор технологий (разной степени), выбор общих принципов и подходов («фреймворк»). Далее на каждом уровне абстракции таких решений наберётся ещё несколько десятков — от выбора подхода к версионированию сущностей до определения порядка сборки репозиториев для деплоя на стенд. Помните, что
архитектура — это то, что важно именно для вас, поэтому это не всегда разговоры о стратегии и высоких материях.
И да, стоимость изменения таких решений в будущем действительно будет выше, чем для других. Именно поэтому во времена big design up-front существовала иллюзия, что такие решения надо принять как можно раньше, в момент старта проекта/создания продукта и как можно «правильнее». Уже тогда это было «сомнительно, но окэ».
Теперь же, в эпоху lean IT практик и agile трансформации SDLC (ключевое свойство которой — заказчик/потребитель больше не готов мириться с отлитыми в бронзе требованиями и решениями, которые меняются раз в цикл) это в принципе невозможно: на момент старта у нас недостаточно информации, мы не можем учесть все аспекты контекста, не можем заглянуть в будущее (привет, расчёты сайзинга — самая «полезная» и «эффективная» часть современного ИТ).
В итоге мы:
🔹 либо
принимаем решение под давлением желания сделать хоть что-то и миримся с необходимостью всё переделать в будущем (возможно, далёком, но, скорее всего, ближайшем)
🔹 либо п
ытаемся отложить принятие решения до момента, когда это действительно необходимо (в англоязычных материалах это называется
last responsible moment) и затем уже принимаем решение (хотелось бы верить, что
«осознанно и рационально», но...)
Что с этим делать и при чем тут архитектор и архитектура - расскажу в следующем посте, а то и так много получилось,
обещал больше одного-двух экранов не писать)
