AI asistent za programiranje može u nekoliko sekundi izraditi uvjerljiv PHP kontroler. Može i kopirati nesiguran upit bazi podataka, ponoviti nejasnu apstrakciju ili dodati novu krajnju točku koja neprimjetno zanemaruje konvencije na koje se vaš tim oslanja. Razlika je često u primjerima koje vidi.

Upute su važne, ali su privremene. Vaš repozitorij trajni je nastavni materijal: kod, testovi, dokumentacija, konfiguracija i sve odluke koje stoje iza njih. Ako su ti materijali jasni i dosljedni, veća je vjerojatnost da će asistent izraditi koristan prvi nacrt. Ako su proturječni, dulja uputa možda će samo bolje interpunkcijski urediti zbrku.

Vaš repozitorij je nastavni program u praksi

Asistent za programiranje ne zna automatski koji su obrasci namjerni, a koji su ostaci migracije. Može naići na tri načina provođenja validacije i nemati pouzdanu osnovu za odabir među njima. Osoba koja se pridružuje timu suočava se s istim problemom, iako može pitati kolegu zašto najstariji primjer navodi na pogrešan zaključak.

Počnite tako da olakšate pronalaženje preporučenog pristupa. Mali, dobro održavan primjer krajnje točke API-ja može naučiti više od opće upute da se „slijede najbolje prakse”. Može pokazati gdje se provodi validacija, kako servis prijavljuje neuspjeh poslovne operacije, kakvu strukturu odgovora klijenti dobivaju i koji test provjerava ugovor.

To ne znači da svaku funkcionalnost treba silom uklopiti u jedan predložak. Krajnja točka za izvještavanje s mnogo operacija čitanja i operacija plaćanja imaju različite potrebe. Cilj je učiniti razloge tih razlika vidljivima kako bi i programeri i asistenti mogli razlikovati namjernu iznimku od slučajnog odstupanja.

Učinite pravi primjer potpunim

Razmotrite krajnju točku koja izrađuje narudžbu. Koristan nastavni materijal za nju obuhvaća više od samog kontrolera. Potpun primjer trebao bi povezati ugovor zahtjeva s aplikacijskim servisom, pohranom podataka, obradom pogrešaka i testovima. Ako izrada narudžbe i rezervacija zaliha moraju uspjeti zajedno, granica transakcije trebala bi biti jasna u kodu koji donosi tu odluku.

Primjerice, servis bi tu granicu mogao izraziti ovako:

public function placeOrder(PlaceOrder $command): Order
{
    return $this->transactions->run(function () use ($command): Order {
        $order = $this->orders->create($command);
        $this->inventory->reserve($order);

        return $order;
    });
}

Primjer je koristan samo ako okolna implementacija ispunjava njegova obećanja. Izvršitelj transakcije mora poništiti promjene ako rezervacija ne uspije, a oba repozitorija moraju sudjelovati u istoj transakciji baze podataka. Test bi trebao provjeriti da nakon neuspjeha ne ostane narudžba. Ako rezervacija poziva vanjski servis, sama transakcija baze podataka ne može poništiti taj poziv; rješenju je potrebna izričita strategija za djelomični neuspjeh.

Ta je razlika važna kada tražite od asistenta da doda slično ponašanje. Prikazana metoda upućuje na atomsku operaciju, ali stvarno jamstvo ovisi o infrastrukturi izvan isječka. Dajte asistentu relevantnu implementaciju i testove te ga zamolite da utvrdi pretpostavke prije proširivanja obrasca.

Navedite ograničenja ondje gdje nastaju promjene

Dobre smjernice u repozitoriju dovoljno su konkretne da utječu na odluku. „Održavajte API-je sigurnima” vrijedan je, ali neodređen savjet. „Provjerite može li autentificirani korisnik pristupiti traženom računu prije nego što vratite njegove fakture” daje programeru nešto konkretno za implementaciju i provjeru.

Trajne smjernice smjestite blizu posla na koji se odnose. Referentna dokumentacija API-ja trebala bi opisivati polja zahtjeva i odgovora, očekivanja u pogledu autorizacije i smislene odgovore na pogreške. Vodič za migraciju baze podataka trebao bi objasniti kako tim postupa s promjenama tijekom postupnog uvođenja novih verzija. Kratka arhitekturna bilješka može zabilježiti zašto granica postoji i kada je iznimka opravdana.

Uskladite te dokumente s implementacijom. Zastario primjer može biti štetniji od nepostojanja primjera jer stvara lažan osjećaj sigurnosti. Kada se konvencija promijeni, zajedno ažurirajte reprezentativni kod i njegovu dokumentaciju; inače repozitorij istodobno podučava dvije međusobno suprotstavljene lekcije.

Testovima izrazite ponašanje, a ne samo pokrivenost

Testovi asistentu daju konkretne primjere onoga što sustav jamči. Koristan test API-ja mogao bi pokazati da valjan zahtjev stvara resurs, da mu drugi račun ne može pristupiti i da se na nevaljan zahtjev vraća dokumentirana pogreška. Ti primjeri pomažu očuvati ponašanje kada se implementacija promijeni.

Testovi imaju i ograničenja. Skup testova koji prolazi ne dokazuje da je novi upit učinkovit, da su ponovni pokušaji sigurni ili da pravilo autorizacije pokriva sve putove. Ta svojstva provjerite izravno. Primjerice, za operaciju koju je moguće ponovno pokušati zapitajte se što se događa ako prvi zahtjev uspije, ali se odgovor izgubi. Ako klijent ponovno pošalje zahtjev, može li operacija stvoriti duplikat? Možda će biti potrebno osmisliti idempotentnost te dodati testove za ponovljene zahtjeve i istodobne pokušaje.

Dajte asistentu jasno ograničen zadatak

Kada repozitorij sadrži dobre primjere, usmjerena uputa može se pozvati na njih. Navedite ponašanje koje treba dodati, relevantan postojeći kod, važna ograničenja i način na koji će se provjeriti uspjeh. Na primjer:

Dodajte krajnju točku za prikaz popisa faktura autentificiranog računa. Slijedite postojeće konvencije za paginaciju i odgovore na pogreške. Osigurajte da upit ne može vratiti fakture drugog računa te dodajte testove za kontrolu pristupa i paginaciju. Istaknite sve pretpostavke koje nedostaju.

Time asistentu zadajete cilj bez propisivanja svakog retka. Sami pregledajte predloženi upit i testove: paginacija zahtijeva stabilan redoslijed, a filtriranje prema računu mora se provesti prije vraćanja rezultata. Ako su performanse važne, pregledajte plan izvođenja upita na reprezentativnim podacima i odlučite je li indeks opravdan.

Uključite i operativnu stvarnost

Aplikacijski kod samo je dio lekcije. Konfiguracija Dockera, varijable okruženja i napomene o uvođenju opisuju kako se servis izvodi. Jasne upute za postavljanje pomažu asistentu predložiti promjene koje odgovaraju razvojnom okruženju, a točan vodič za uvođenje otkriva ovisnosti između izdanja aplikacije i migracija baze podataka.

Za promjenu sheme dokumentirajte razdoblje kompatibilnosti: koje verzije aplikacije moraju raditi s kojom shemom i kada se stari stupci ili putovi izvršavanja koda mogu ukloniti. Nemojte pretpostavljati da svi spremnici istodobno prelaze na novu verziju. Ako bi migracija mogla zaključati veliku tablicu ili potrajati dulje vrijeme, procijenite je u odnosu na bazu podataka i radno opterećenje koji se koriste prije nego što zakažete uvođenje.

Ni najbolja uputa ne može nadoknaditi repozitorij koji skriva odluke na kojima se temelji. Uložite u primjere koji rade, testove koji objašnjavaju posljedice i dokumentaciju koja ostaje usklađena sa stvarnošću. Tako ćete AI asistentu dati bolji materijal iz kojeg može učiti, a svakom programeru u timu jasnije polazište.