Код пам’ятає всі версії бізнесу

ТЕХНІЧНИЙ БОРГ НЕ ЗАВЖДИ ІСТОРІЯ ПРО ПОГАНИХ РОЗРОБНИКІВ

Є дуже зручний спосіб говорити про старі системи. Назвати їх legacy. Згадати технічний борг. Відкрити код. Серйозно подивитися на нього. А потім пояснити, що попередня команда свого часу ухвалила неправильні архітектурні рішення, і саме тому систему тепер потрібно модернізувати.

Мені ніколи не подобалося таке пояснення.

Іноді я дуже добре знаю, хто побудував цю систему. Ми. Я пам'ятаю, чому багато з цих рішень були прийняті. Пам'ятаю ті обговорення. Пам'ятаю вимоги маркетингу. Пам'ятаю, як ми аналізували поведінку користувачів і переносили елементи інтерфейсу, тому що дані показували, що так буде краще. Пам'ятаю, як змінювався сам продукт.

І більшість із тих рішень були абсолютно виправданими на той момент. Але це зовсім не означає, що вони залишаються правильними назавжди.

Мартін Фаулер описує технічний борг як додаткові зусилля, яких потребує розвиток системи через її внутрішню будову. Водночас він робить важливе уточнення, яке дуже часто губиться в розмовах про legacy-проєкти: технічний борг далеко не завжди є наслідком необережних чи невдалих рішень. Він може накопичуватися навіть у продуктах, над якими працювали сильні команди й ухвалювали цілком розумні рішення.

Саме ця думка для мене принципова.

Тому що продукт, який активно розвивається п'ять років, неминуче накопичує власну історію. Кнопку перенесли не випадково. Умова в коді з'явилася не випадково. Виняток виник тому, що одна категорія товарів справді працювала інакше. Нове поле додали тому, що в той момент бізнесу були потрібні саме ці дані. Інтеграцію написали навколо тієї системи, яка існувала тоді.

Продукт продовжує розвиватися.

Код усе це пам'ятає. І через кілька років може виявитися, що код зберігає більше версій бізнесу, ніж пам'ятає нинішня команда.

ХОРОШИЙ РОЗРОБНИК НЕ МОЖЕ ПРОСТО ВИДАЛИТИ ТЕ, ЩО ЗДАЄТЬСЯ ЗАЙВИМ

Саме тут і починається справжня вартість.

Досвідчений розробник відкриває код і знаходить стару умову. На перший погляд вона виглядає зайвою. Можливо, так і є. Але професіонал не може відповідально сказати: «Я не розумію, навіщо це потрібно. Значить, видаляємо.»

Те, що я не розумію призначення цього коду, ще не означає, що він більше не потрібен.

Спочатку потрібно розібратися. Чому це взагалі з'явилося? Від чого це залежало? Чи залежить від цього щось зараз? Це було пов'язано з окремою категорією товарів, з маркетинговою кампанією, з певним статусом продукту, зі старою інтеграцією? Цей код взагалі ще виконується? Бізнес досі використовує цей процес? Чи ця функція давно померла, а може нею досі користується одна людина в компанії двічі на місяць, просто всі інші вже про це забули?

І тоді починається зовсім інша робота. Читання коду. Перегляд історії. Пошук залежностей. Аналіз даних. Тестування поведінки. Розмови з людьми. Іноді навіть із тими, хто працював над цим проєктом кілька років тому.

І дуже часто відповідь звучить приблизно так: «Мені здається, що це вже не потрібно.»

Здається. Саме в цьому і проблема.

Не можна будувати відповідальну підтримку програмного продукту навколо фрази «мені здається». Робота починається ще до того, як починаються зміни. І ця робота коштує грошей.

У програмній інженерії вже давно досліджують проблему program comprehension, розуміння існуючих систем, адже саме воно займає значну частину часу під час розвитку програмного забезпечення. Останні дослідження навіть починають відокремлювати класичний технічний борг від того, що називають cognitive debt та intent debt, втрати спільного розуміння системи й причин, через які колись були прийняті певні рішення.

Коли ми працювали над цими проєктами, ми, звичайно, не користувалися такими термінами.

Моє формулювання було значно простішим. Чому ми витрачаємо стільки часу, щоб згадати те, що колись самі ж побудували?

ІНОДІ СИСТЕМА СТАРІЄ САМЕ ТОМУ, ЩО ПРОДУКТ ЖИВ

Один із наших e-commerce проєктів працює вже понад п'ять років.

Першу версію ми побудували на базі open-source CMS. На той момент це було правильне рішення. Бізнесу потрібна була платформа для електронної комерції. Основний фокус був на B2C. B2B існував, але залишався лише невеликою частиною бізнесу. Саме так і була побудована система.

Потім ми почали її розвивати. І дуже активно. Ми аналізували поведінку користувачів. Дивилися теплові карти. Переробляли картки товарів. Змінювали каталог. Покращували інтерфейс. Переміщували елементи. Додавали нову логіку. Інтегрували нові сервіси.

Бізнес продовжував працювати. Продукт продовжував змінюватися разом із ним.

І саме це тут найважливіше. Система не пролежала п'ять років без змін. Вона прожила ці п'ять років разом із бізнесом.

Покинута система стає застарілою тому, що її ніхто не чіпає. Живий продукт, навпаки, може ставати дедалі складнішим саме тому, що над ним постійно працюють.

Коли дивишся лише на фінальний код, цього вже не видно. Ти бачиш умови, старі стилі, правила, винятки, логіку, яка ніби дублює іншу логіку. Але не бачиш зустрічей. Не бачиш теплової карти трирічної давності. Не бачиш маркетингової кампанії, яка змусила змінити картку товару. Не бачиш, чому одна категорія товарів майже пів року жила за окремими правилами.

Код залишився. Контекст, ні.

Іноді технічний борг не ознака того, що продуктом ніхто не займався. Навпаки. Це ознака того, що ним займалися багато років.

ПОТІМ БІЗНЕС ЗМІНИВСЯ

Сам по собі технічний борг не став причиною перебудови системи. Якби все було так просто, ця стаття навряд чи з'явилася б.

Сталося дещо важливіше. Змінився сам бізнес.

Кілька років тому основним напрямком був B2C. B2B існував, але залишався другорядним. Потім клієнт прийшов із зовсім іншим запитом. Тепер B2B і B2C потрібно було розділити майже порівну.

На перший погляд це виглядає як звичайне завдання для сайту. Додати окремий розділ. Створити ще кілька сторінок. Переробити навігацію. Технічно все це можна зробити.

Але справа була вже не в сторінках. B2B і B2C перестали бути двома розділами одного сайту. Вони стали двома різними напрямками бізнесу. З різними завданнями. З різним позиціонуванням. З різними сценаріями користувача. З різними вимогами до інформації. Бізнес фактично розділився на дві повноцінні частини.

А система все ще вважала одну з них просто окремим розділом.

Паралельно значно ускладнилися фільтри. Каталог уже вимагав структурної перебудови. Картку товару потрібно було переосмислити. Пошук більше не відповідав новим вимогам. ERP та CRM інтеграції стали набагато глибшими. Сам бізнес диверсифікувався. Почали з'являтися нові продукти.

І ми вже обговорювали питання, яких п'ять років тому просто не існувало. Наприклад, як каталог має працювати в AI-інтерфейсах і як змінюється сам пошук.

Стара CMS не провалилася. І питання навіть не полягало в тому, чи можемо ми продовжувати її доопрацьовувати. Могли.

Справжнє питання було іншим. Яку частину нової системи ми вже будуємо всередині старої, продовжуючи називати це доопрацюваннями?

МОЖЛИВО, ВИ ВЖЕ БУДУЄТЕ НОВУ СИСТЕМУ. ПРОСТО ВСЕРЕДИНІ СТАРОЇ.

Таке майже ніколи не відбувається за один день. Ніхто не збирає зустріч і не каже: «З понеділка ми починаємо перебудовувати платформу, але залишаємо стару архітектуру.»

Усе відбувається значно буденніше. З'являється ще одна задача. Потрібно повністю переробити картку товару. Добре. Потім каталог. Потім фільтри. Пошук. Нова інтеграція. Інший сценарій для B2B. Нова логіка продуктів. Ще один напрямок бізнесу більше не вписується в існуючу структуру даних.

Кожне із цих завдань окремо виглядає цілком логічним. Кожне можна оцінити. Кожне можна обґрунтувати. І майже кожне окремо коштує дешевше, ніж повна перебудова системи. Саме тому компанія продовжує доопрацьовувати існуючу платформу.

Але в якийсь момент варто перестати дивитися на задачі окремо. Подивитися потрібно на напрямок, у якому рухається продукт.

Якщо ми вже повністю переглядаємо картку товару, перебудовуємо каталог, змінюємо пошук, переписуємо фільтри, ускладнюємо інтеграції, будуємо нові сценарії взаємодії користувача, що саме ми намагаємося зберегти? Домен? Стару структуру бази даних? Десятки умов, які вже страшно видаляти? Назву CMS в адміністративній панелі?

Іноді ви вже будуєте нову систему. Просто робите це всередині старої.

Саме тут звичне порівняння починає вводити в оману. Так, наступне доопрацювання коштуватиме дешевше за повну перебудову. Звісно. Але питання вже не в тому, чи дешевше окрема задача №1847 за нову платформу.

Питання в іншому. Що відбувається, якщо наступні двадцять важливих задач починаються однаково? Спочатку потрібно зрозуміти, що вже існує. Це вже зовсім інша стаття витрат.

ПОСТІЙНА ЦІНА РОЗУМІННЯ

Мені здається, саме цю частину майже завжди недооцінюють.

Коли говорять про вартість підтримки продукту, зазвичай мають на увазі години розробки. Додати функцію. Виправити помилку. Оновити інтеграцію.

Але в зрілій системі значна частина роботи відбувається ще до того, як розробник узагалі може відповідально почати зміни.

Хорошому спеціалісту потрібно зрозуміти систему. CI допомагає. Тести допомагають. Git-історія допомагає. Документація теж. AI дедалі краще допомагає читати незнайомий код і швидше знаходити взаємозв'язки. Усе це справді корисно.

Але жоден із цих інструментів не відповідає на головне бізнес-питання. Чи існує сьогодні причина, через яку цей код колись був написаний?

Код може пояснити, що робить певна умова. Git покаже, коли вона з'явилася. Тести покажуть, що зламається, якщо її видалити. Але це не відповідає на інше питання. Чи потрібна ця поведінка бізнесу сьогодні?

Хтось усе одно має пов'язати стару реалізацію з нинішньою моделлю роботи компанії.

Саме тому я дедалі частіше думаю про технічний борг не лише як про проблему коду. Він створює ще одну, менш очевидну статтю витрат. Ми постійно платимо за те, щоб знову зрозуміти систему, перш ніж отримуємо можливість її змінити. І дуже часто ми платимо за це не один раз.

Один розробник розбирається з логікою каталогу. Через кілька місяців інший повертається до тих самих рішень, працюючи вже над пошуком. Ще через рік команда змінює картку товару й знову проходить частину того самого шляху.

Система може працювати бездоганно. Але дедалі більше часу команда витрачає не на створення наступної версії продукту. А на те, щоб зрозуміти, чому попередні версії виглядали саме так.

Останні дослідження почали називати цю проблему більш точно. Робота Маргарет-Енн Сторі 2026 року відокремлює технічний борг від cognitive debt та intent debt: код може лишатись, поки спільне розуміння системи й причини рішень руйнуються. Сама Сторі формулює цю різницю стисло: технічний борг ускладнює зміну систем, тоді як cognitive debt ускладнює їх розуміння.

Це дуже близько до того, що я спостерігав на практиці.

Стара система далеко не завжди є головною проблемою. Іноді найдорожче те, що вона постійно змушує команду згадувати бізнес, якого в такому вигляді вже давно не існує.

ПЕРЕБУДОВА НЕ ПОКАРАННЯ ДЛЯ СТАРОЇ СИСТЕМИ

Саме тому мені ніколи не подобалася типова риторика навколо модернізації legacy-систем. Стара платформа стримує ваш розвиток. Попередня архітектура була помилкою. CMS більше не масштабується. Legacy-система себе вичерпала.

Іноді все це правда. Але далеко не завжди.

У нашому випадку перша система багато років чудово виконувала свою роботу. Вона підтримувала бізнес. Розвивалася разом із продуктом. Давала нам дані. Давала розуміння поведінки користувачів. Саме завдяки їй компанія виросла до того моменту, коли B2B і B2C стали двома окремими напрямками.

Чому я маю називати це провалом?

Ми перебудовуємо систему не тому, що колись ухвалили неправильне рішення. Ми перебудовуємо її тому, що змінилися умови, у яких це рішення працює.

Змінився бізнес. Змінилися вимоги. Продукт накопичив власну історію. І в якийсь момент вартість адаптації старої структури почала конкурувати з вартістю побудови нової архітектури навколо бізнесу, яким компанія є сьогодні.

Це вже зовсім інша розмова.

Перебудова не означає, що стара система була помилкою. Іноді вона лише означає, що стара система настільки добре виконала свою роботу, що бізнес виріс із задачі, для якої вона колись створювалася.

НАЙСКЛАДНІШЕ ЗРОЗУМІТИ, КОЛИ НАСТАВ ЦЕЙ МОМЕНТ

Хотілося б, щоб існувала проста формула. Технічний борг досяг 37%, час перебудовувати систему. Розробники витрачають понад 14 годин на розуміння старої логіки, перебудовуємо. CMS має більше шістдесяти модулів, перебудовуємо.

На жаль, таких формул не існує. І я з великою обережністю ставлюся до людей, які готові дати готову відповідь, навіть не вивчивши продукт.

П'ятирічна система може ще багато років залишатися абсолютно життєздатною. А дворічна вже може не відповідати бізнесу. Старий код не означає поганий код. Технічний борг сам по собі не означає, що все потрібно починати спочатку. І бізнес, який росте, автоматично не потребує кастомної розробки.

Потрібно дивитися на картину цілком. Скільки ключових частин продукту вже потребують структурних змін? Скільки часу команда витрачає не на розробку, а на розуміння старої логіки? Скільки нових вимог доводиться вбудовувати в припущення, зроблені для бізнесу кількарічної давності? Чи стають інтеграції складнішими? Чи змінилася модель продукту? Чи змінився шлях користувача? Чи змінився сам бізнес?

І головне. Якщо подивитися на найближчі два-три роки, ми справді продовжуємо розвивати існуючу систему? Чи вже повільно замінюємо кожну її важливу частину, задачу за задачею?

Саме це питання здається мені найважливішим. У який момент ми починаємо витрачати більше часу на розуміння старої системи, ніж на проєктування наступної?

Не кожен продукт доходить до цієї точки. Наш, дійшов.

КОД ПАМ'ЯТАЄ ВСІ ВЕРСІЇ БІЗНЕСУ

Іноді я відкриваю старий проєкт і впізнаю власні рішення. Я пам'ятаю, чому ми перенесли саме цей елемент. Пам'ятаю, чому змінилася картка товару. Пам'ятаю частину логіки. Іншу, вже ні.

І це абсолютно нормально. П'ять років, великий термін для живого цифрового продукту. Змінюються люди. Змінюються команди. Змінюється маркетинг. Змінюються клієнти. Змінюється бізнес.

А система зберігає все. Стиль. Умову. Виняток. Поле. Інтеграцію. Одну кнопку, яка несе за собою п'ять років рішень.

Настає момент, коли всі ці рішення ще має сенс поступово очищати й упорядковувати. Але настає й інший момент. Коли наступну версію бізнесу вже чесніше проєктувати з того, чим компанія стала сьогодні, а не намагатися реконструювати її через логіку, що накопичувалася роками.

Найважче — вчасно це визнати. Особливо тоді, коли стара система все ще працює. Особливо тоді, коли її будував ти сам.

Можливо, саме тоді це найважче.

Стара система складається з рішень, які свого часу були абсолютно правильними. Саме тому їх потрібно спочатку зрозуміти, перш ніж вирішувати, чи варто будувати на них далі.

Іноді після такого аналізу найвідповідальнішим рішенням стає не додати ще один шар. А створити наступну систему.