AI asistent može u nekoliko sekundi napisati uvjerljivu PHP metodu. Teže je pitanje može li tu metodu sigurno smjestiti u pozadinski sustav koji ne razumije. Kada se poslovna pravila skrivaju u kontrolerima, nuspojave vrebaju u povratnim pozivima modela, a promjena odgovora API-ja ovisi o trima nedokumentiranim konvencijama, brzina tipkanja prestaje biti glavno ograničenje.

Refaktoriranje radi jasnoće poboljšava uvjete u kojima rade i razvojni inženjeri i AI alati. Jasne granice olakšavaju pronalaženje odgovarajućeg koda, razumijevanje njegovih obveza i provjeru je li predložena promjena ispravna. Cilj nije učiniti kod ugodnim modelu. Cilj je učiniti važne odluke vidljivima, a promjene lakšima za provjeru.

Učinite poslovnu odluku vidljivom

Čest je izvor zabune metoda koja miješa nekoliko vrsta posla: čitanje zahtjeva, odlučivanje o tome ispunjava li narudžba uvjete za popust, ažuriranje baze podataka i slanje e-pošte. Svaki korak može biti opravdan, ali zajedno prikrivaju pravilo koje je doista važno.

Počnite odvajanjem odluke od mehanizma koji je provodi. Primjerice, pravilo za popust može prihvatiti potrebne podatke i vratiti rezultat. Kontroler može obraditi HTTP zahtjev, dok aplikacijski servis koordinira pohranu i ostale učinke. Time razvojni inženjer ili asistent dobiva uže pitanje na koje treba odgovoriti: „Kako treba promijeniti ovo pravilo?” umjesto „Što radi cijeli ovaj obrađivač zahtjeva?”

final class DiscountPolicy
{
    public function discountFor(int $subtotalCents, bool $isMember): int
    {
        if (!$isMember || $subtotalCents < 10000) {
            return 0;
        }

        return intdiv($subtotalCents * 10, 100);
    }
}

Primjer koristi cjelobrojne iznose u centima i zaokružuje ih prema dolje cjelobrojnim dijeljenjem. Ti su izbori vidljivi, ali i dalje moraju odgovarati pravilima proizvoda za valute i zaokruživanje. Izdvajanje metode ne razrješava poslovnu odluku; ono timu daje jasno mjesto na kojem je može navesti i testirati.

Definirajte smislene ugovore na granicama

Nazivi pomažu, ali ugovori imaju veću težinu. Metoda nazvana process() čitatelju govori malo o tome što prihvaća, što mijenja ili kako može zakazati. Metoda s jasno određenom svrhom, eksplicitnim tipovima i dokumentiranim uvjetom pogreške daje korisna ograničenja i ljudskim pregledavateljima i AI alatima.

Na granici API-ja opišite strukture zahtjeva i odgovora, pravila validacije, zahtjeve za autorizaciju i relevantne odgovore o pogreškama. Uključite ponašanje na koje se klijenti mogu osloniti, primjerice je li operaciju sigurno ponoviti. Ako se zahtjev za stvaranje može ponoviti nakon isteka vremena čekanja, ključ idempotentnosti i pravila njegove pohrane mogu spriječiti dvostruko izvršavanje. Sam ključ nije dovoljan: implementacija mora definirati njegov opseg, čuvati rezultat odgovarajuće vrijeme i dosljedno obrađivati istodobne zahtjeve.

Isto načelo vrijedi unutar aplikacije. Sučelje repozitorija treba jasno naznačiti vraća li se za zapis koji nedostaje null ili se baca iznimka. Servis koji šalje poruke treba jasno iskazati svoje nuspojave. Dosljednost je važnija od usvajanja pomodnog obrasca: predvidljive lokalne konvencije olakšavaju praćenje promjena.

Jasno navedite nuspojave i puteve pogrešaka

Kod koji generira AI često izgleda uvjerljivo u scenariju uspješnog izvršavanja. Pozadinski sustavi moraju se nositi i s poništavanjem transakcije u bazi podataka, istekom mrežnog vremena čekanja, ponovnim pokušajem radnog procesa ili zahtjevom koji stigne dvaput. Refaktoriranje je vrijedno kada otkrije te situacije prije nego što netko zatraži od asistenta da proširi takav kod.

Razmotrite krajnju točku za narudžbe koja zapisuje narudžbu i šalje e-poruku s potvrdom. Ako se e-poruka pošalje prije nego što se transakcija u bazi podataka potvrdi, njezino poništavanje može ostaviti kupca s potvrdom narudžbe koja ne postoji. Ako se e-poruka šalje nakon potvrde transakcije, a proces se prije toga sruši, narudžba može postojati bez potvrde.

Jedna je mogućnost transakcijski izlazni spremnik: spremite narudžbu i zapis koji opisuje e-poruku koju treba poslati u istoj transakciji baze podataka, a zatim prepustite njezinu isporuku radnom procesu. Radni proces mora podnositi ponovne pokušaje, a postupak isporuke mora imati način postupanja s duplikatima. To uvodi dodatne mehanizme, pa je najkorisnije kada ih cijena gubitka obavijesti opravdava. Arhitektonska odluka i njezini kompromisi trebaju biti navedeni uz kod ili u kratkom zapisu o odluci.

Uspostavite povratnu petlju koju asistent može koristiti

Jasnoća bez provjere i dalje ostavlja prostor za pogreške počinjene s uvjerenjem. Koristan skup testova opisuje opažljivo ponašanje na nekoliko odgovarajućih razina: testove pravila za poslovna pravila, integracijske testove za ponašanje baze podataka i API testove za važne ishode vidljive klijentima. Testovi trebaju obuhvatiti značajne rubne slučajeve i puteve pogrešaka, a ne samo reproducirati strukturu implementacije.

Ponovljivo lokalno okruženje također smanjuje nejasnoće. Docker može pomoći timu da pokreće aplikaciju i njezine ovisnosti s dosljednom konfiguracijom, ali slika kontejnera ne jamči da će se lokalno i produkcijsko okruženje ponašati jednako. Dokumentirajte potrebne varijable okruženja, način inicijalizacije baze podataka i naredbe koje projekt doista podržava. Ne unosite tajne podatke u konfiguraciju koja se pohranjuje u repozitorij.

Kada tražite od AI asistenta promjenu, navedite mu relevantni ugovor, ograničenja i korake provjere. Zatražite da utvrdi pretpostavke i puteve pogrešaka na koje promjena utječe. Zatim pregledajte razlike u kodu kao i svaki drugi doprinos: provjerite autorizaciju, rukovanje podacima, upite, povratnu kompatibilnost i operativne posljedice. Uspješno izvršen skup testova jest pokazatelj, ali ne i dokaz da je obuhvaćeno svako važno ponašanje.

Refaktorirajte ondje gdje se to isplati

Nemojte svaku klasu pretvarati u sučelje ni svaku metodu dijeliti na mnoštvo pomoćnih metoda od jednog retka. Dodatne razine posredovanja mogu prikriti ponašanje jednako učinkovito kao i dugačka funkcija. Dajte prednost promjenama koje uklanjaju stvarnu prepreku: pravilo koje je teško testirati, nuspojavu koja iznenađuje pozivatelje ili upit čiji je trošak teško uočiti.

Radite u malim koracima. Utvrdite postojeće ponašanje prije nego što ga promijenite, očuvajte izvana vidljive ugovore osim ako je njihova promjena namjerna te pregledajte nastale upite i puteve izvršavanja kada su performanse važne. Čišća apstrakcija koja uvodi dodatni upit bazi podataka za svaku stavku u velikoj zbirci može biti pogoršanje, čak i ako se kod lako čita.

Najbolji pozadinski sustav spreman za AI jest onaj u kojem se novi član tima može pouzdano snalaziti: njegova pravila imaju nazive, njegove granice imaju ugovore, a njegove su pogreške uzete u obzir. AI može ubrzati rad unutar te strukture, ali trajna je prednost jednostavnije inženjersko prosuđivanje koje je lakše primijeniti svaki put kada se sustav promijeni.