Це рідко називають проблемою архітектури
Нові функції виходять довше, ніж усі очікували. Команда постійно повертається до тих самих багів — виправляє в одному місці, а вони випливають в іншому. Кожен реліз відчувається напружено: маленький деплой перетворюється на маленьку кризу. І десь по дорозі частина продукту стає тією частиною, яку ніхто не хоче чіпати. Вона працює. Технічно. Ніхто не знає чому. І ніхто не хоче бути тим, хто це з'ясує.Ніхто не називає це «архітектурою». Це називають «нам потрібно більше розробників», «наша команда повільна» або «ця технологія була помилкою». Тож компанії наймають більше людей, змінюють фреймворки, перезапускають проєкти. А ті самі симптоми повертаються через півроку — бо справжня проблема ніколи не була в технології чи в талантах.
Справжня проблема: продукт, що переростає сам себе
Продукт непомітно став складнішим за самого себе — складнішим за проблему, яку мав вирішувати, складнішим, ніж команда, що його підтримує, здатна одразу утримати в голові.Ця складність не з'являється одразу. Вона накопичується крок за кроком: функція, прикручена під тиском дедлайну, залежність, додана тому що так швидше, рішення, яке мало сенс для команди з п'яти людей і так і не було переглянуте, коли їх стало п'ятдесят. Кожне окремо виглядає розумним. Разом — вони складаються в проблему.
Що таке архітектура насправді
Це не діаграми. І не найновіший фреймворк у резюме.Архітектура — це набір рішень, які визначають, чи може продукт продовжувати змінюватися, не ламаючи сам себе.Гарна архітектура не заявляє про себе нічим ефектним — саме тому в неї так легко недоінвестувати. Немає демо на тему «в цій системі легко розібратися». Немає фічі, яку можна показати стейкхолдеру під назвою «ми можемо додати нову інтеграцію за два дні замість двох місяців». Її результат — негативний: це всі інциденти, яких не сталося, всі спринти, що пройшли за планом, усі дзвінки о другій ночі, яких ніхто не отримав.
Як це відчувається, коли все працює
Замість цього ви відчуваєте ефект. Естімейти починають справджуватися. Новий розробник може прочитати код і зрозуміти, що він робить, а не лише що він мав би робити. Релізи перестають бути подіями, до яких готуються як до випробування. Продукт може рости — більше користувачів, більше функцій, більше інтеграцій — і кожен етап росту не перетворюється на перебудову з нуля.Це і є справжній тест, і водночас найкраще діагностичне запитання для будь-якої команди: чи можете ви змінювати цю систему, не боячись її?Якщо відповідь «так» — архітектура робить свою справу, хвалив її хтось за це чи ні. Якщо відповідь «ні» — більше людей у команді цього не виправить. Так само, як і переписування системи тим самим способом, яким її будували вперше.
Чому цього ніхто не помічає, поки воно не зникне
Ніхто не хвалить будівлю за фундамент. Люди помічають фундамент тоді, коли стіни починають тріскатися, — а на той момент виправлення коштує набагато дорожче, ніж коштувало б зробити все правильно з самого початку.З софтом те саме, тільки тріщини проявляються як зірвані дедлайни, плинність розробників і продукт, який зі зростанням стає не легше, а важче продавати.Гарна архітектура непомітна. Це не недолік того, як ми про неї говоримо. У цьому весь сенс — і саме тому варто ставитися до неї серйозно ще до того, як це доведеться помітити самому бізнесу.