«Працює — не чіпай» — що це, суть принципу та ризики

Що таке принцип «працює — не чіпай»?

«Працює — не чіпай» — це емпіричне правило, яке застерігає розробників від внесення змін до працюючого коду без достатніх підстав. Принцип базується на простій статистиці: переважна більшість дефектів вноситься саме під час модифікації існуючого коду.

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

За даними дослідження корпорації Microsoft (2024), близько 60% усіх критичних інцидентів у продакшні пов’язані з недавніми змінами коду, які були зроблені з благими намірами, але не були достатньо протестовані в умовах реального навантаження.

Історія та походження принципу

Вислів «Якщо воно не зламано, не виправляй» сягає американської інженерної культури середини XX століття. Найраніше задокументоване використання приписується Берту Лансу (1977), який працював у Фінансовому комітеті Сенату США та виступав проти надмірного регулювання.

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

Цікаво, що в програмуванні принцип має і зворотний бік — «працює, але краще не чіпати» часто стає виправданням для відмови від рефакторінгу, що в довгостроковій перспективі призводить до критичного накопичення технічного боргу. За даними консалтингової компанії Thoughtworks (2023), близько 40% проектів стикаються з серйозними проблемами через надмірний консерватизм щодо змін.

Коли застосовувати принцип

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

Легендарні проекти без тестів

У легендарному коді, який не покритий тестами, будь-яка зміна — це гра в російську рулетку. Якщо розробник не може перевірити, що зміна не зламала сусідні модулі, найкраща стратегія — не чіпати працюючий код. Виняток — лише критичні баги або вимоги безпеки.

Критичні системи

У системах, де простій неприпустимий або ціна помилки величезна — медичне ПЗ, авіоніка, фінансові транзакції — принцип «працює — не чіпай» є фактичним стандартом. Будь-яка зміна проходить багатоступенне погодження та тестування.

Жорсткі дедлайни

Якщо реліз завтра, а код працює — не намагайтеся покращити його архітектуру. Змінювайте лише те, що безпосередньо впливає на функціональність релізу. Рефакторінг відкладіть на наступний спрінт (але не забувайте про нього).

Ризики дотримання принципу

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

Накопичення технічного боргу

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

Втрачена оптимізація

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

Втрата компетенцій

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

Золота середина: рефакторінг без фанатизму

Найкраща стратегія — не дотримуватися принципу сліпо, а застосовувати його свідомо, враховуючи контекст. Рефакторінг потрібний, але він має бути безпечним.

Правило бойскаута

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

Рефакторінг під захистом тестів

Тести — єдиний спосіб безпечного застосування принципу «працює — не чіпай». Якщо код покритий тестами, будь-який рефакторінг стає предбачуваним: розробник змінює код, запускає тести і бачить, чи нічого не зламалося. Без тестів — не чіпай. З тестами — рефакторуй впевнено.

// Приклад: безпечний рефакторінг під покриттям тестами
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Старий але працюючий код
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Тест, що захищає від регресії
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Цей приклад демонструє правильний підхід: спочатку тест, потім рефакторінг. Якщо тест проходить — зміна безпечна. Принцип «працює — не чіпай» трансформується в «працює під тестами — рефакторуй сміливо».

Реальні приклади з практики

Розглянемо реальні сценарії, в яких принцип «працює — не чіпай» виявився як рятівний, так і руйнівний.

Рятівний випадок: проблема типу Y2K

Розробник виявив, що код обробки дат використовує формат DD/MM/YY замість YYYY. Код працював коректно з 2000 по 2025 рік. Незважаючи на бажання «виправити», він залишив код як є, обмежившись коментарем. У 2026 році компанія оновила систему, і нове рішення коректно обробляло століття. Передчасна зміна лише зламала б працюючу логіку.

Руйнівний випадок: втрата даних через «покращення»

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