Рефакторинг: єдиний напрям, результат якого не покажеш на демонстрації. Зовні після нього нічого не змінюється. Змінюється вартість усього, що робитимуть далі: нова функція знову коштує стільки, скільки має, а правка в одному місці перестає ламати інше.
Це напрям із блоку корпоративного розвитку. Його підключають, коли продукт уже працює і переходить від MVP до MMP та MLP, а код, написаний заради швидкої перевірки гіпотези, має витримати роки розвитку. Орієнтир вартості напряму в прайсі Ingello: $4700.
Як технічний борг виглядає для бізнесу
Власник рідко бачить код, але добре бачить наслідки. Терміни на схожі задачі зростають від кварталу до кварталу. Після кожного релізу спливають помилки в місцях, яких ніхто не торкався. Розробники просять «спершу все переписати». Заміну платіжної системи, CRM чи ШІ-провайдера оцінюють у місяці, бо зовнішній сервіс викликається з десятків місць напряму.
Коли він окуповується, а коли ні
Окуповується, коли правки в одному місці регулярно ламають інше, коли нова функція коштує помітно дорожче за таку саму пів року тому і коли новий розробник входить у проєкт тижнями. Не окуповується, якщо продукт скоро закриють або гіпотезу ще не перевірено. Тоді чесніше дописати як є і повернутися до коду, коли стане зрозуміло, що продукт житиме.
Що входить у роботу
У прайсі напрям описано двома пунктами: покращення якості коду та підготовка до довгострокової підтримки й масштабування. На практиці робота йде в такому порядку:
- Мапа проблемних зон: де правки найчастіше спричиняють помилки, де дублюється логіка, яких модулів ніхто не наважується торкатися.
- Страховка: тести на найгрошовитіші сценарії ще до того, як код почнуть змінювати.
- Розподіл відповідальності: бізнес-правила переїжджають у сервіси, а контролери й шаблони лишаються тонкими.
- Розв'язання залежностей: між кодом і зовнішніми сервісами з'являється власний шар, через який ідуть усі виклики.
- Лад у даних: невдалі зв'язки й поля виправляють через міграції, з планом перенесення даних і відкату.
- Чистка: видалення дублів, мертвого коду та бібліотек, якими ніхто не користується.
- Єдині стандарти коду та автоматичні перевірки, щоб порядок не розмивався після того, як команда піде з проєкту.
Кожен крок викочується окремо, і система працює між кроками. Рефакторинг, який на два місяці заморожує продукт, ми не пропонуємо.
Що Ви отримуєте
- Передбачувані оцінки: схожі задачі знову коштують схоже.
- Менше помилок після релізів у місцях, які не змінювали.
- Можливість змінити підрядника, вендора чи сервіс без переписування половини системи.
- Код, у який новий розробник входить за дні, а не за тижні.
- Готовність до зростання навантаження й кількості користувачів без заміни фундаменту.
Скільки коштує і від чого залежить
Орієнтир у прайсі: $4700 за напрям. Обсяг залежить від розміру кодової бази й від того, які зони важливі для бізнесу просто зараз: переписувати все поспіль майже ніколи не потрібно. Впливає й наявність тестів: якщо їх немає, частина бюджету йде на страховку перед змінами.
Якщо код писала інша команда, першим кроком іде аудит: $800 за текстовий звіт або $2400 з раннім прототипом доопрацювання. У ньому фіксуються проблемні зони, технічний борг і ризики, і лише після цього зрозуміло, що вигідніше: стабілізувати систему, рефакторити окремі модулі чи проєктувати заміну.
Чому без тестів це ризик
Змінювати робочий код, не маючи способу перевірити, що він лишився робочим, небезпечна затія. Тому автоматизація тестування зазвичай іде разом із рефакторингом або безпосередньо перед ним.
Що ламається, якщо заощадити
- Кожна наступна функція дорожча за попередню, і бюджет розвитку йде на обхід старих рішень.
- Команда починає боятися торкатися коду, і продукт перестає змінюватися слідом за ринком.
- Залежність від вендора стає пасткою: його ціни й умови змінюються, а піти дорого.
- Зрештою лишається тільки переписувати з нуля, а це в рази дорожче за своєчасне прибирання.
Приклад із практики
Найдорожча залежність в ШІ-проєкті часто не модель, а її API. Щойно десяток інструментів навчився ходити в один конкретний інтерфейс, зміна вендора перетворюється на проєкт на місяці. Ми розв'язали це локальним шлюзом: він приймає запити в попередньому форматі, транслює їх іншому провайдеру й маршрутизує між моделями. Код проєктів, які його викликають, не змінюється ані на рядок, а двох провайдерів можна тримати одночасно й перемикатися під час збою. Подробиці в кейсі про адаптер зміни AI-провайдера.
Той самий принцип розв'язання ми застосовуємо до платіжних систем, CRM і будь-яких зовнішніх сервісів: один шар, через який ідуть усі виклики, замість звернень із кожного модуля.
Куди далі
Суміжні напрями: оптимізація сервера та документування. Мапа всіх етапів у стратегії розробки застосунку. Як ми підходимо до архітектури систем, описано на сторінці Ingello Systems.
На безкоштовній консультації архітектор Ingello розбере, де код гальмує розвиток продукту, і запропонує порядок робіт без зупинки релізів. Після неї Ви отримуєте розрахунок ціни й термінів за етапами. Обговорити стан кодової бази.
