Програмування часто сприймають як абстрактну математику: формули, логіка, нулики й одинички, світ чистих ідей, де немає ні тертя, ні гравітації. Почасти це правда. Але що довше я проєктую реальні системи, то більше переконуюся, що живуть вони за законами, дивовижно схожими на фізичні. У них є маса, інерція, навантаження, втома матеріалу й навіть щось на кшталт ентропії.
Ця стаття трохи філософська, чесно попереджаю. Але з філософії тут виростають цілком практичні висновки про те, чому одні системи живуть роками, а інші розсипаються за пів року, хоча на старті виглядали однаково.
Логіка: фундамент, який не можна скасувати
В основі будь-якої програми лежить логіка. Якщо замовлення оплачено, його можна відвантажити. Якщо товару немає на складі, його не можна зарезервувати. Ці правила абсолютні всередині системи, як закони логіки в математиці. Порушиш їх, і система почне продукувати абсурд: відвантажувати неоплачене, продавати неіснуюче.
Найцінніше в логіці системи те, що вона відображає логіку бізнесу. Не логіку програміста, не логіку фреймворка, а реальні правила, за якими працює компанія. І коли я говорю про архітектуру, я насамперед говорю про те, наскільки точно логіка коду збігається з логікою предметної галузі. Це фундамент. Усе інше будується на ньому.
Статика: скелет системи
У кожної системи є статична частина. Це структура бази даних, набір сутностей і звʼязків між ними, класи й модулі коду, їхні залежності одне від одного. Статика описує, з чого система складається, так само як креслення мосту описує його балки, троси й опори.
У статики є властивість, яку я називаю статичною складністю. Що більше сутностей, звʼязків, шарів і залежностей, то важче систему вивчити. Новий розробник відкриває проєкт і бачить триста таблиць, тисячу класів і павутину звʼязків між ними. Щоб зрозуміти, як усе влаштовано, йому потрібні тижні. Статична складність робить систему важкою для вивчення.
Частина цієї складності неминуча: якщо бізнес складний, його модель теж буде складною. Але значна частина народжується з недбалості. Таблиці-дублікати, які зʼявилися, бо ніхто не знав про наявну. Модулі, що залежать одне від одного по колу. Назви, які нічого не кажуть. Це зайва вага, яку міст змушений нести.
Динаміка: що відбувається, коли мостом їдуть
А тепер динаміка. Це те, що відбувається, коли система працює. Потоки даних, запити користувачів, фонові задачі, інтеграції з іншими сервісами, навантаження в пікові години. Міст на кресленні й міст, яким їдуть вантажівки в годину пік під бічним вітром, це дві різні речі.
Динамічна складність робить систему непередбачуваною. Коли багато процесів працюють одночасно, взаємодіють, чекають одне одного, конкурують за ресурси, виникають ефекти, які неможливо побачити, дивлячись на код. Дві операції, кожна з яких правильна, разом дають неправильний результат. Система, яка чудово працює на десятьох користувачах, падає на тисячі. Помилка зʼявляється раз на тиждень і зникає, коли її починають шукати.
Найнеприємніші проблеми в моїй практиці завжди були динамічними. Статичну помилку видно в коді. Динамічну видно лише в русі, і часто лише в продакшені, під реальним навантаженням, у найневідповідніший момент.
Стійка динаміка
Інженери, які будують мости, давно знають парадокс: міст, який зовсім не гнеться, не найміцніший. Жорстка конструкція під вітром і навантаженням накопичує напруження й у якийсь момент ламається. Добрий міст проєктують так, щоб він трохи гнувся, пружинив, гасив коливання й повертався у вихідне положення. Це і є стійкість.
Із системами те саме. Мистецтво архітектури, на мій погляд, полягає у створенні того, що я називаю стійкою динамікою. Система має бути здатна змінюватися без руйнування своєї фундаментальної логіки. Додається нова функція, зростає навантаження, змінюється бізнес-процес, а система пружинить і адаптується, замість того щоб тріскатися.
Як цього досягти на практиці?
- Тримати статику простою: менше сутностей, менше звʼязків, зрозумілі назви. Легкий міст простіше втримати.
- Ізолювати частини одна від одної: зміна в одному модулі не має поширюватися хвилею по всій системі.
- Захищати логіку: правила бізнесу мають жити в одному місці, а не дублюватися в десяти, щоб за зміни навантаження чи інтерфейсу вони лишалися незмінними.
- Спостерігати за динамікою: моніторинг, логи, метрики. Міст без датчиків напруження руйнується раптово, міст із датчиками попереджає заздалегідь.
- Перевіряти під навантаженням до того, як навантаження прийде саме.
І не тільки
Фізичні аналогії на цьому не закінчуються. У систем є інерція: що більша й старша система, то важче змінити її напрям. Є ентропія: без постійного догляду будь-який код поступово приходить у безлад, як кімната, у якій ніхто не прибирає. Є втома матеріалу: рішення, які були правильними пʼять років тому, перестають витримувати сьогоднішні вимоги.
Я не стверджую, що програмування це фізика. Але мислення інженера, який будує мости, корисне будь-якому архітекторові програм. Воно змушує думати не лише про те, як система виглядає на кресленні, а й про те, як вона поводитиметься під вітром.
Саме тому ми в Ingello приділяємо так багато уваги статиці: Fractal генерує структуру даних і коду за єдиними правилами, щоб скелет системи був легким і передбачуваним. А динаміку ми спостерігаємо й перевіряємо на реальних даних, бо лише в русі видно, чи витримає міст. Якщо Ви хочете зрозуміти, наскільки стійка Ваша система, спитайте не «як вона влаштована», а «що з нею буде, якщо завтра навантаження зросте вдвічі, а бізнес змінить один процес». Відповідь на це питання і є справжньою оцінкою архітектури.
