Більшість переписувань коду обслуговують інженера, а не бізнес
Одного літа кілька тижнів поспіль я прокидався о 4-й ранку, щоб переписати код, який мій роботодавець уже заплатив комусь написати. Він щодня працював у продакшені й був побудований на CakePHP. CakePHP я знав погано, тож кожен файл здавався мені неправильним. Зате я знав Laravel і любив у ньому працювати. Тож у вільний час, без чийогось прохання, я переносив цю штуку по шматках, замінюючи все на пакети Illuminate, аж поки старий фреймворк не зник зовсім.
Ми змерджили цей код. Наступний проєкт ми теж почали на Laravel. І жодного разу я не навів аргумент, чому це було варто робити, бо не було, принаймні для бізнесу. Застосунок виконував ту саму роботу для тих самих користувачів з тією самою швидкістю, що й раніше. Переписування покращило рівно одну річ: як цей код відчувався для мене.
Ось патерн, який варто назвати вголос. Більшість переписувань обслуговують інженера — чого він хоче навчитися, що ображає його смак, що добре виглядатиме на співбесіді, — а не компанію, яка платить зарплату.
Робочий код — це реєстр багів, які хтось уже виправив
Найсильніший аргумент проти переписування — не обсяг роботи. Це пам'ять. Код, що роками працює в продакшені, це письмовий запис кожного бага, на який хтось наштовхнувся і тихо виправив. Дивна умова, повторна спроба з підозрілим таймаутом, здебільшого це рубцева тканина, і кожен рубець позначає інцидент, якого ви не бачили. Джоел Спольскі говорив про це ще 2000 року, назвавши повне переписування найгіршою стратегічною помилкою, яку може зробити софтверна компанія.
Викиньте код, і викинете разом з ним усі виправлення. А тоді зустрінете ті самі баги знову, у продакшені, на очах у тих самих користувачів.
Я працював із системою на Perl, якій на той момент було вже понад десять років, і з саморобною PHP CMS приблизно того ж віку. Жодна з них не виглядала так, як я написав би сьогодні. Обидві просто працювали. Компанії ніколи не вкладали в них додаткові інвестиції, і це було правильне рішення. Код давно себе окупив, і кожен спокійний рік, коли він продовжував обслуговувати трафік, був чистим прибутком.
Незнайоме — це не те саме, що зламане
Ось ознака, яку я проґавив у власній історії. Я був упевнений, що код на CakePHP неправильний, але насправді я так і не вивчив CakePHP по-справжньому. Незнайоме — не те саме, що зламане. Коли ви погано знаєте інструмент, усе, що на ньому побудоване, здається помилкою, бо ви ще не бачите причин за тими рішеннями. Це відчуття «тут усе не так» найчастіше — просто звук того, що ви ще не розібралися.
Почніть із протилежного припущення: люди до вас не були дурнями. Вони ухвалювали рішення, які відповідали тодішньому сценарію використання й обмеженням. Код має саме таку форму не просто так, навіть якщо причина вам уже не видна.
Коли доторкнутися до коду — правильне рішення
Усе це не означає «заморозити все». Це ледаче прочитання правила «не зламано — не чіпай», і саме так ви опиняєтеся у 2026 році з рантаймом, для якого вже не виходять патчі безпеки. Деякий борг справді доводиться сплачувати. Ось як приблизно виглядають чесні причини для дії — не повний список, а лише ті, з якими стикаюся я сам:
- Рантайм або ключова залежність вийшли з підтримки, мають відкриті CVE, і немає шляху оновлення.
- Систему розуміє лише одна людина, і вона щойно подала заяву на звільнення.
- Через архітектуру кожна нова фіча коштує втричі більше, ніж мала б, і цю тенденцію можна показати цифрами.
- Бізнесу потрібна можливість, під яку поточний код ніколи не був розрахований.
Остання причина — саме там, де я перебуваю зараз. Я переписую сервіс, і значну частину набору коду виконує AI-агент, тому що нам потрібно, щоб він робив те, для чого його ніколи не будували. Код працює. Бізнес його переріс. Це причина, за якою стоїть конкретна цифра.
Тест, що відрізняє справжнє переписування від переписування заради самолюбування, простий: чи можете ви поставити цифру на біль? CVE, податок на швидкість розробки, найм, якого ви не можете зробити, запуск, який ви пропустите. Якщо жодна цифра не з'являється, перед вами не більше ніж уподобання щодо стилю.
AI робить переписування дешевим для набору тексту й таким же складним для правильного результату
AI справді зміщує цю математику, але не так, як стверджує більшість. Новий аргумент звучить так: переписування знову стало дешевим: модель здатна перенести цілий модуль за пів дня, то чому б і ні. Але набір тексту ніколи не був дорогою частиною переписування. Дорогим було повторне відкриття причин.
Агент генерує заміну за хвилини. Він не знає, чому старий код мав той дивний таймаут, бо причина живе в Slack-треді 2021 року та в постмортемі, на який ніхто не поставив посилання з коду. Тож він видає щось чисте й правдоподібне, з якого зникла вся рубцева тканина. Ви викочуєте це в продакшен, і зустрічаєте старі баги знову, цього разу без контексту, який мав перший автор, коли їх виправляв. Швидка генерація коду, що забув власні виправлення, — це не знижка.
Ця чиста версія теж не залишиться улюбленою надовго. Причина, чому сьогоднішній код читається як купа чужих помилок, — у тому, що він пережив зіткнення з реальністю. Написана AI заміна заслужить ту саму долю. Через два роки якийсь інженер відкриє її, не побачить, чому вона має саме таку форму, і відчує ідентичний потяг переписати її «як слід».
Дешевша генерація не зупиняє цей цикл. Вона лише полегшує його запуск і ускладнює зупинку. Вихід — не повільніша модель. Вихід — записувати причини простою мовою, щоб наступна людина або наступна модель отримувала не лише «що», а й «чому».
Тож перш ніж переписувати те, що працює, ідіть шукати цифру. Якщо не знайдете жодної, то ремонту потребує ваше терпіння, а не код.