Как вы думаете, нужно ли архитектуру на вашем текущем проекте подвергнуть масштабному пересмотру и исправлению? Ставлю на то, что большинство читателей ответят положительно. И эта часть именно про это. В ней мы рассмотрим:
1. Когда сложившаяся архитектура подлежит масштабным изменениям.
2. Что не менее важно, когда лучше оставить, как есть.
3. Ключевые признаки проблем в архитектуре.
4. Основные способы исправления таких проблем.
Но для начала мы вспомним, что было в предыдущих сериях. В первой части мы прошлись по теории и выяснили:
1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично;
2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура;
3. Что самое важное свойство архитектуры — максимальная независимость команд друг от друга;
4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling — характеристика связи двух точек системы/кодовой базы; а cohesion — характеристика того, насколько плотно упакованы такие связи в компоненты.
Во второй части мы уже перешли к практике построения архитектуры с нуля. Мы узнали:
1. Что попытки угадать с архитектурой до старта проекта обычно проваливаются.
2. Что маленькие команды работают буквально в разы эффективнее, чем большие.
3. Что лучший способ разделить софт между командами - делать это постепенно. Начать с одной команды и уже затем дробить систему по обнаруженным в процессе разработки границам.
Теперь перейдем к вопросу, что же делать, если «все уже украдено до нас».
