Refaktoriranje se često prikazuje kao zadatak čišćenja: nešto što treba planirati nakon što je „pravi” posao dovršen. Takav pristup je skup. U pozadinskom sustavu kod koji isporučuje funkcionalnosti ujedno je i kod koji mora preživjeti sljedeću promjenu sheme, neuspjelu integraciju, skok prometa i incident tijekom dežurstva.

Redovito održavanje nije potraga za estetskim savršenstvom. Riječ je o tome da promjene ostanu financijski prihvatljive. Kada struktura PHP aplikacije odgovara odlukama koje mora donositi, programeri mogu raditi s pouzdanjem. Kada to nije slučaj, svaki naizgled mali zahtjev postaje rizična ekspedicija kroz kontrolere, upite, konfiguraciju i nedokumentirane pretpostavke.

Refaktoriranje štiti brzinu isporuke

Brzina razvoja funkcionalnosti i refaktoriranje nisu suprotstavljeni prioriteti. Postaju suparnici tek kada se refaktoriranje tretira kao velik, zaseban projekt s nejasnim ishodom. Mala, ciljana poboljšanja uz rad na proizvodu obično povećavaju brzinu isporuke jer uklanjaju ponavljajuće prepreke.

Razmotrite krajnju točku naplate čiji kontroler provjerava unos, izračunava porez, zapisuje narudžbe, poziva pružatelja usluge plaćanja, šalje e-poštu i oblikuje odgovor. Možda danas radi, ali njezine su odgovornosti isprepletene. Dodavanje novog pružatelja plaćanja ili ponavljanje neuspjele obavijesti sada riskira promjenu redoslijeda poslovno kritičnih radnji.

Bolja podjela odgovornosti ne zahtijeva moderan arhitektonski dijagram. Zahtijeva da odgovornosti budu izričite:

• kontroler prevodi HTTP zahtjeve i odgovore;
• aplikacijska usluga koordinira slučaj uporabe;
• domenska logika izračunava pravila i promjene stanja;
• repozitoriji i klijenti upravljaju pohranom podataka i udaljenim sustavima;
• pozadinski poslovi upravljaju radom koji ne mora biti dovršen prije odgovora.

Te granice olakšavaju promišljanje o kvarovima. Istek vremena plaćanja pripada klijentu za plaćanje i tijeku rada koji odlučuje treba li pokušati ponovno. Neispravno oblikovan zahtjev pripada HTTP granici. Kršenje jedinstvenosti u bazi podataka možda treba prevesti u smislen ishod na razini aplikacije. Refaktoriranje pomaže smjestiti te odluke tamo gdje se mogu testirati i razumjeti.

Započnite ondje gdje je promjena već bolna

Najbolji ciljevi za refaktoriranje rijetko se biraju pregledavanjem najstarijih datoteka. Tražite kod koji redovito usporava rad: klasu koju se svi boje dirati, upit kopiran u nekoliko krajnjih točaka, uvjet koji raste za svaku novu vrstu korisnika ili Docker postavku koju može popraviti samo jedan programer.

Ponavljajuća zbunjenost koristan je dokaz. Ako programer stalno mora ponovno otkrivati zašto metoda postoji, kod traži jasniji naziv, manji opseg ili test koji objašnjava. Ako se vrijednost mora mijenjati na četiri mjesta, traži jedan izvor istine.

Najprije napravite najmanje sigurno poboljšanje

Refaktoriranje najbolje funkcionira kao niz koraka koji čuvaju ponašanje. Prije premještanja logike utvrdite trenutačno ponašanje pomoću testova, primjera zahtjeva, zapisnika ili ciljane ručne provjere. Zatim napravite jednu strukturnu promjenu i provjerite je.

Na primjer, izdvojite izračun poreza iz kontrolera prije redizajniranja cijelog modula narudžbi:

final class TaxCalculator
{
    public function calculate(int $subtotalCents, float $rate): int
    {
        return (int) round($subtotalCents * $rate);
    }
}

Primjer je namjerno uzak. U stvarnom financijskom sustavu stope, pravila zaokruživanja i upravljanje valutama zaslužuju izričite domenske tipove i testirana poslovna pravila. Poanta nije da svaki izračun treba klasu. Poanta je da smisleno pravilo ne bi trebalo biti skriveno između raščlanjivanja zahtjeva i JSON serijalizacije.

Refaktorirajte API-je oko ugovora, a ne praktičnosti

Refaktoriranje pozadinskog sustava može slučajno pokvariti klijente čak i kada interni testovi ostanu zeleni. API-ji su ugovori: polja odgovora, statusni kodovi, ponašanje paginacije, poruke validacije, pravila idempotentnosti i očekivanja vezana uz vrijeme mogu biti važni nekome drugome.

Pri preoblikovanju krajnje točke odvojite interno poboljšanje od vanjske promjene. Održite javni ugovor stabilnim dok, gdje je moguće, zamjenjujete pojedinosti implementacije. Ako se ugovor mora promijeniti, omogućite promišljen put migracije umjesto da potajno promijenite polje iz niza znakova u objekt.

Za krajnje točke za zapisivanje, idempotentnost zaslužuje posebnu pozornost. Ponovni pokušaj klijenta nakon mrežnog kvara ne smije stvoriti drugu narudžbu samo zato što je prvi odgovor izgubljen. Pojedinosti implementacije razlikuju se, ali tijek rada treba prepoznati ponovljeni zahtjev i sigurno vratiti ili rekonstruirati izvorni rezultat.

Slično tome, udaljeni pozivi ne bi trebali biti unutar transakcije baze podataka osim ako to model konzistentnosti doista zahtijeva. Držanje transakcije otvorenom dok se čeka API treće strane povećava vrijeme zaključavanja i otežava rukovanje greškama. Često je sigurniji dizajn potvrditi lokalno stanje, zabilježiti događaj ili posao u istoj transakciji, a zatim obaviti vanjski rad asinkrono uz ponovne pokušaje i mogućnost nadzora.

Čišćenje baze podataka je arhitektonski posao

Promjene baze podataka među najvrjednijim su prilikama za refaktoriranje jer se loši obrasci pristupa podacima brzo šire. Krajnja točka koja učitava popis zapisa, a zatim unutar petlje upituje povezane podatke, može skroman zahtjev pretvoriti u desetke ili stotine upita.

Izmjerite prije nego što to promijenite. Zatim odaberite najmanje složeno rješenje: unaprijed učitajte odnose kada to podatkovni model podržava, dohvatite potrebne zapise jednim upitom, dodajte odgovarajući indeks za dokazani obrazac pristupa ili redizajnirajte krajnju točku koja vraća daleko više podataka nego što je korisnicima potrebno.

Indeksi nisu bezopasni ukrasi. Mogu poboljšati čitanja uz dodatni prostor za pohranu i opterećenje pri zapisivanju. Redovito održavanje znači pregledavati indekse u kontekstu stvarnih upita, a ne dodavati ih za svaki stupac koji se pojavljuje u filtru.

Migracije zaslužuju istu disciplinu. Migracija sigurna za implementaciju uzima u obzir postojeće retke, ponašanje zaključavanja, verzije aplikacije koje se izvode tijekom uvođenja i ograničenja vraćanja promjena. Dodavanje stupca koji dopušta null obično je lakše postupno uvesti nego odmah dodati stupac koji ne dopušta null sa skupom zadanom vrijednošću u veliku tablicu. Promišljeno popunite postojeće podatke, implementirajte kod koji razumije oba stanja, a zatim pooštrite ograničenja kada su podaci spremni.

Neka okruženje izvođenja bude jednostavno

Docker može učiniti lokalni razvoj ponovljivim, ali samo ako konfiguracija ostane promišljena. Fiksirajte glavne izbore radnog okruženja koje vaša aplikacija treba, zadržite konfiguraciju u varijablama okruženja ili upravljanim tajnama te izbjegavajte ugrađivanje promjenjivih vjerodajnica u slike.

Korisno pitanje za redovito održavanje jednostavno je: može li novi programer pokrenuti aplikaciju dokumentiranim naredbama i dobiti iste usluge, portove i ovisnosti kao ostatak tima? Ako odgovor ovisi o nezapisanom lokalnom zaobilaznom rješenju, riječ je o operativnom dugu.

Produkcijske implementacije trebaju jednaku jasnoću. Izgradite nepromjenjiv artefakt, primijenite promjene baze podataka kroz kontrolirani postupak, izložite signale spremnosti i zdravlja prikladne platformi te učinite zapisnike dovoljno korisnima za praćenje zahtjeva kroz aplikaciju. Refaktoriranje konfiguracije vrijedno je kada ubrzava dijagnosticiranje kvarova, a ne samo kada preuređuje YAML.

Koristite testove kao zaštitne ograde, a ne kao ritual

Testovi čine refaktoriranje sigurnijim kada opisuju ponašanje koje je važno. Usmjereni jedinični test može zaštititi poslovno pravilo; integracijski test može provjeriti upit repozitorija i granicu transakcije; API test može očuvati ugovor odgovora. Nijedan pojedinačni sloj ne obuhvaća sve.

Krhak skup testova sam je po sebi signal za refaktoriranje. Testovi koji ovise o privatnim pojedinostima implementacije obeshrabruju čišćenje jer ih bezopasno restrukturiranje ruši. Radije provjeravajte vidljive ishode: vraćene vrijednosti, pohranjeno stanje, emitirane događaje ili HTTP odgovore.

Prije veće promjene zapišite invarijante koje moraju ostati istinite. Primjeri uključuju „zaliha nikada ne postaje negativna”, „uspješno plaćanje bilježi se jednom” ili „korisnik ne može čitati zapise druge organizacije”. Te tvrdnje timu daju praktičnu definiciju sigurnosti.

Redovito održavanje navika je odgovornog upravljanja

Zdrave kodne baze nisu one bez nespretnih područja. To su one u kojima su nespretna područja vidljiva, ograničena i stalno se poboljšavaju. Redovita praksa refaktoriranja pretvara održavanje iz nelagodnog naknadnog razmišljanja u dio uobičajene odgovornosti inženjerskog tima.

Ključna promjena je sljedeća: refaktoriranje nije uglađivanje koda nakon što je vrijednost isporučena. To je način na koji tim čuva svoju sposobnost isporučivanja vrijednosti kada stigne sljedeća važna promjena.