Postoji predstava da je refaktorisanje veliki zahvat — višednevni posao, rizik, „clean‑up sprint" koji treba isplanirati, odvojiti vreme i progurati kroz gomilu pregleda koda. U praksi, najbolja refaktorisanja su ona najmanja: ona koja možeš da uradiš dok čekaš da se build završi, dok kolega završava code review, ili u onih petnaest minuta pre dnevnog stand‑up‑a.
Kada ove male navike uđu u svakodnevni rad, kvalitet koda i stabilnost projekta dramatično rastu. Tehnički dug se drži pod kontrolom bez velikih, bolnih intervencija — a ti kao inženjer postaješ neko ko „ostavlja kod boljim nego što ga je zatekao".
U ovom tekstu delim devet kratkih, praktičnih refactoring rutina koje zahtevaju 15 minuta ili manje, a dugoročno prave ogromnu razliku. Svaku ilustrujem na jednom malom C# projektu za obradu porudžbina (RefactoringDemo TODO: upload and add link to GH) — direktorijum Before sadrži kod pre refaktorisanja, a After primenjuje sve obrasce o kojima govorimo.
1. Izdvajanje metode (Extract Method): prvi korak ka čistom kodu
Ako postoji „gateway refactoring" — ulazna tačka za sve ostale navike — to je Extract Method. Ideja je jednostavna: čim primetiš blok koda koji počinje da „priča svoju priču", obeleži ga i izdvoj u zasebnu metodu sa jasnim imenom.
Pogledaj kako izgleda jedan monolitan metod u našem primeru — validacija, kalkulacija, slanje u magacin, obaveštenje i čuvanje, sve u jednom:
Srećom, moderna okruženja za razvoj softvera (IDE) nam nude alate za automatski refactoring, što umnogome olakšava posao i smanjuje rizik. Evo primera kako te alate možemo iskoristiti u Visual Studio okruženju:
Uz malo drugačije korake, slično iskustvo nude i druga razvojna okruženja: IntelliJ IDEA, VS Code i Eclipse IDE.
Zašto ovo radi? Smanjuje mentalno opterećenje — čitaš pet naziva metoda umesto šezdeset linija koda. Svaka metoda je prirodna granica za testiranje. A verovatnoća greške prilikom budućih izmena drastično opada, jer ne moraš da razumeš celinu da bi izmenio jedan deo.
2. Uklanjanje dupliranog koda: DRY u malim koracima
Duplirani kod je najbrži generator tehničkog duga i bagova. Problem nije što je ružan — problem je što kad ispraviš bug na jednom mestu, zaboraviš da ga ispraviš na drugom. Ali ne moraš da rešiš sve duplikate odjednom. Počni od najuočljivijih.
U našem primeru, validacija porudžbine se pojavljuje na tri različita mesta — u Process(), ponovo u sredini istog metoda, i treći put u DoWork():
Možemo krenuti od izdvajanja metoda za mesta koja deluju kao duplikati kao i u prethodnom primeru:
Na prvi pogled ove tri metode se dosta razlikuju. Međutim, izdvajanje metoda nam omogućava da se fokusiramo i vidimo na koji način taj deo koda komunicira sa svojom okolinom. Kada ih svedemo na najveći zajednički činilac, kompajler će nam pomoći da svaku kopiju pravilno iskoristimo na mestu pozivanja:
U tom procesu možemo koristiti sistem za kontrolu revizija (npr. Git) da vidimo kako je taj deo koda izgledao pre nego smo krenuli u refactoring. U ovakvim situacijama testovi mnogo pomažu da verifikujemo da zaista nismo promenili vidljivo ponašanje.
Mini‑strategija: identifikuj dva mesta gde je kod skoro isti, izdvoj zajednički deo u privatnu metodu, a razlike ostavi na mestu. Ne mora sve odjednom — svako uklanjanje jednog duplikata je korak napred.
3. Poboljšavanje imena: najjeftiniji refactoring ikada
Ovo je refactoring koji košta nula rizika, a donosi ogromnu vrednost. Pravilo je jednostavno: ako moraš da pogledaš implementaciju da bi razumeo naziv — preimenuj.
U našem primeru:
Process() → ne govori šta se obrađuje
DoWork() → ne govori ništa
x → ne govori čemu služi ta promenljiva
flag → ne govori šta signalizira
A kada im damo bolje nazive:
ProcessOrder() — jasno šta obrađuje
ProcessAllOrders() — jasno šta radi sa listom
total — odmah se zna da je u pitanju ukupan iznos
isExpired — odmah se zna šta proverava
Ima više načina da pokrenemo ovaj refactoring u Visual Studio, ali jedan od najlakših je da samo promenimo naziv:
Potom otvorimo akcije prečicom „Ctrl+.“ Ili iz kontekstnog menija, kao u prvom primeru:
Visual Studio takođe nudi i direktno Rename komandu u kontekstnom meniju ili preko prečice, obično „F2“ ili „Ctrl+R, Ctrl+R“, ali ovo može da varira, pa proverite pre upotrebe.
Dobar naziv je dokumentacija koja se nikad ne zastareva. Za razliku od komentara koji vremenom postaju netačni, ime metode ili promenljive je uvek ažurno — jer je deo koda koji kompajler proverava. Pet minuta preimenovanja koje ćeš danas uraditi uštedećeš nekom kolegi (ili sebi za šest meseci) sat vremena zbunjenog čitanja koda. A sa modernim IDE alatima, Rename refactoring je siguran — menja sve reference odjednom, bez rizika da nešto propustiš. Ovo, naravno, ne važi za public API, kod koga treba biti posebno oprezan jer obično ne znamo gde se sve koristi.
4. Lokalizuj promene: „Boy Scout Rule" u praksi
Robert Baden‑Powell je rekao: „Ostavi logorsko mesto čistijim nego što si ga našao." Isti princip važi za kod. Kad radiš na metodi ili klasi, izdvoj pet minuta da počistiš okolinu.
U našem primeru nailazimo na klasične „boy scout" probleme — zakomentarisan mrtav kod:
Nakon ispravke ovoga jednostavno nema. Obrisano, jer Git pamti istoriju bolje od komentara.
Pored toga: uskladi nazive promenljivih, formatiraj nepravilne delove, rasporedi using‑e, ukloni nepotrebne komentare. Ovih pet minuta čišćenja čini kumulativnu razliku koja se meri mesecima ušteđenog vremena.
5. Enkapsulacija „sitnih curenja": sakrij detalje implementacije
Jedno od najčešćih „curenja" u C# kodu je javno izlaganje mutabilnih kolekcija. Kad imaš:
Zameni sa:
Ova promena traje trideset sekundi, a sprečava čitavu kategoriju bagova — slučajno brisanje stavki, dodavanje duplikata izvana, zaobilaženje validacije. Pet minuta enkapsulacije danas znači jedan bag manje sledeće nedelje.
6. Jedna odgovornost: mali koraci ka SRP‑u
Single Responsibility Principle ne zahteva da „ispraviš arhitekturu" u jednom danu. Dovoljno je da izdvojiš jedan deo logike koji ne pripada klasi u kojoj se nalazi.
U našem primeru, OrderProcessor sam računa, sam šalje u magacin, sam obaveštava kupca i sam čuva porudžbinu. Bilo bi mnogo bolje da su magacin i obaveštenja prebačeni u zasebne servise (IWarehouseService, INotificationService), a OrderProcessor samo koordinira tok.
Nisi morao da naletiš na SRP da bi osetio problem — dovoljno je da se zapitaš: „Da li bih, kad menjam logiku za obaveštenja, trebalo da gledam kalkulaciju cena?" Ako je odgovor ne — vreme je za izdvajanje.
Pogledajmo kako to izgleda na primeru magacina. Prvi korak je „Extract Method“:
Potom se oslonimo na kompajler i automatske akcije koje nudi Visual Studio da kreiramo nove klase. Pretvaramo se da postoji sve što nam je potrebno, a on će za nas popuniti praznine:
Iako je malo potrajalo, konačno stižemo i do kraja. Sada imamo sve što nam je potrebno da bismo prebacili implementaciju na odgovarajuće mesto. Kopiraćemo sadržaj metode koju smo već ranije izdvojili i nalepiti na odgovarajuće mesto, koje lako možemo pronaći:
Ključno je ne preterivati. Nemoj da izdvajaš sve u prvom prolazu. Izdvoji jednu stvar koja očigledno ne pripada — to je dovoljno za danas. Sutra izdvoji sledeću. Za nedelju dana, klasa je fokusirana, a ti nisi proveo nijedan vikend na „velikom refaktorisanju".
7. Pretvaranje „magičnih brojeva" u konstante
Magični brojevi su tihe ubice čitljivosti. Kad u kodu vidiš 5000, 0.9m ili 1.2m, moraš da pogađaš šta znače:
Vrlo lako ih možemo zameniti konstantama:
Bonus: kada se prag za popust promeni, menjaš ga na jednom mestu. Ne pretražuješ ceo projekat da bi pronašao svako pojavljivanje broja 100. A kolege odmah razumeju poslovnu logiku bez čitanja dokumentacije — DiscountThreshold je sam po sebi objašnjenje.
Zašto ove male navike čine ogromnu razliku?
Nijedan od ovih koraka ne zahteva više od petnaest minuta. Nijedan ne zahteva odobrenje tehničkog lidera ili poseban sprint. A ipak, kad se primenjuju dosledno, efekat je transformativan:
Tehnički dug se smanjuje pre nego što postane problem — ne „jednog dana", nego danas.
Stabilnost raste bez posebnih sprintova za stabilizaciju.
Juniori brže razumeju postojeći kod, jer je čitljiviji i konzistentniji.
Pažnja prema detaljima postaje navika — a to je ključna inženjerska veština koja se prenosi na sve ostale aspekte posla.
Kada se ove rutine spoje, dobijaš kod koji je čitljiviji, stabilniji i bezbedniji za promene. A ti dobijaš reputaciju inženjera koji ostavlja stvari boljima nego što su bile.
Zato — sledeći put kad otvoriš fajl da popraviš bug, pogledaj oko sebe. Uskladi ime promenljive. Izvuci metodu. Obriši mrtav kod. Zameni magični broj konstantom. Sakrij listu iza IReadOnlyList. Uvedi interfejs za jednu zavisnost.
Petnaest minuta. To je sve što je potrebno. Ne postoji „idealan trenutak" za refaktorisanje — taj trenutak je svaki put kad otvoriš fajl. Kad ovo postane navika, prestaje da bude zadatak i postaje jednostavno — način na koji pišeš kod.
Prateći kod: Kompletan C# projekat sa Before i After verzijama svih primera iz ovog teksta nalazi se na github.com RefactoringDemo (TODO: upload example code to GH). Iskoristite ga da isprobate tehnike koje smo pomenuli i uverite se da je to zaista moguće.
0 komentara