Чому так часто радять переписати
Чужий код завжди виглядає гірше за свій. Розібратись у ньому важче, ніж написати наново, принаймні так здається в перший тиждень. Плюс переписування цікавіше: нові технології, чиста архітектура, ніяких компромісів. Для розробника це найприємніший варіант. Для бізнесу він найризикованіший.
Це не означає, що порада завжди хибна. Це означає, що її треба перевірити.
Чого коштує переписування
Поки пишеться нова система, стара має жити, і зміни в ній потрібні, отже їх роблять двічі. Нова система на старті вміє менше за стару, бо стара накопичувала функції роками, і половина з них ніде не описана. Термін «три місяці» майже завжди перетворюється на пів року, бо обсяг стає зрозумілим лише в процесі. І в день запуску нової системи у неї нові помилки, які нікому ще не відомі, замість старих, до яких усі звикли.
Якщо після цього переписування все ще виглядає правильним рішенням, воно, можливо, і є правильним. Але зазвичай є дешевший шлях.
Що зазвичай працює замість цього
Тести навколо критичних сценаріїв, щоб зміни перестали бути страшними. Оновлення версій PHP і залежностей. Розбір одного або двох найгірших модулів, а не всієї системи. Черги там, де щось робиться синхронно і гальмує. Індекси й переписані запити там, де повільно. Кожен із цих кроків дає результат за дні або тижні, а не місяці, і після кожного можна зупинитись.
Якщо конкретний модуль справді дешевше переписати, ніж лагодити, його переписують. Окремо, з тестами, з можливістю відкотити. Це не те саме, що переписувати всю систему.
Як перевірити пораду
Попросити конкретики. Не «код жахливий», а які саме сценарії ламаються, які зміни неможливі, скільки часу займає типова доробка і чому. Якщо відповіді конкретні, порада варта уваги. Якщо у відповідь загальні слова про архітектуру, це радше звичка.
Друга думка коштує кілька днів аудиту. Документ із трьома варіантами, кожен із ціною, і він ваш незалежно від того, з ким ви будете працювати далі. Порівняно з ціною помилкового переписування це дешева перевірка.