„Ради — не дирај” — шта је то, суштина принципа и ризици

Шта је принцип „ради — не дирај”?

Принцип „Ради — не дирај” (енгл. „If it ain't broke, don't fix it”) — то је емпиријско правило које упозорава програмере од уношења промена у радни код без довољних основа. У основи принципа лежи једноставна статистика: огромна већина дефеката уноси се управо у процесу модификације постојећег кода.

Принцип није догма — то је пре хеуристика која помаже у доношењу одлука у условима неизвесности. Што је кодовна база сложенија и запетљанија, већа је вероватноћа да ће „невина” промена покварити нешто што нико није очекивао да поквари.

Према истраживању корпорације Мајкрософт (2024), око 60% свих критичних инцидената у продукцији повезано је са недавним променама кода које су унете са добрим намерама, али нису довољно тестиране у условима реалног оптерећења.

Историја и порекло принципа

Идиома „If it ain't broke, don't fix it” потиче из америчке инжењерске културе средине 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. године. Упркос жељи да „поправи” — оставио је код какaв јесте, ограничивши се на коментар. 2026. године компанија је ажурирала систем, а ново решење је већ исправно обрађивало векове. Превремена промена би покварила радну логику.

Разорни случај: губитак података због „побољшања”

Инжењер одлучио је да „побољша” стари, али радни код за увоз података, заменивши га модерном библиотеком. Није узео у обзир да је стара библиотека обрађивала специфичан рубни случај који није био документован. Након релиза — масовни губитак података. Принцип „ради — не дирај” је прекршен, а цена грешке била је две недеље рада тима на опоравку.