Značajke umjetne inteligencije rijetko podbace zato što model ne može proizvesti tekst. Podbace zato što se od modela traži da radi bez logike koja vašem softveru daje smisao.

Stupac baze podataka nazvan status ne govori umjetnoj inteligenciji smiju li se “arhivirani” zapisi vratiti. Krajnja točka API-ja ne otkriva koje korisničke uloge mogu odobriti povrat novca. Definicija Docker usluge ne objašnjava da se zadatak može pokrenuti tek nakon što je plaćanje podmireno. Ta pravila postoje, ali su često raspršena po kontrolerima, klasama za validaciju, SQL upitima, radnicima reda čekanja, zastavicama značajki i glavama iskusnih inženjera.

Ako želite da umjetna inteligencija obavlja koristan posao unutar stvarnog pozadinskog sustava, važan problem nije samo pisanje upita. Riječ je o tome da skrivena logika sustava postane eksplicitna, dostupna i testabilna.

Vaša baza koda sadrži više od koda

Većina produkcijskih sustava ima najmanje tri sloja znanja. Prvi je strukturni: tablice, klase, rute, sheme zahtjeva i granice usluga. Drugi je ponašajni: prijelazi stanja, pravila autorizacije, validacija, ponovni pokušaji i obrada pogrešaka. Treći je kontekstualni: zašto ograničenje postoji, koji kompromis štiti i koje su iznimke namjerne.

Umjetna inteligencija može iz izvornog koda zaključiti fragmente sva tri sloja, ali zaključivanje nije pouzdan ugovor. Model može vidjeti uvjetnu naredbu i pogrešno razumjeti predstavlja li ona poslovno pravilo, privremeno zaobilazno rješenje ili ponašanje radi kompatibilnosti sa starijim sustavom.

Praktični je cilj pretvoriti važno implicitno znanje u artefakte koje mogu koristiti i ljudi i alati. To ne znači dokumentirati svaki redak. Znači dokumentirati odluke koje bi bilo opasno nagađati.

Započnite s odlukama koje imaju posljedice

Ne zaslužuje sva skrivena logika jednaki trud. Najprije se usredotočite na područja u kojima bi uvjerljivo formuliran odgovor umjetne inteligencije mogao stvoriti netočnu ili skupu promjenu:

• Granice dozvola i izolacija zakupaca.
• Kretanje novca, naplata, zalihe i nepovratne operacije.
• Strojevi stanja s ograničenim prijelazima.
• Pravila zadržavanja podataka, brisanja i privatnosti.
• Pozadinski zadaci, ponovni pokušaji, idempotentnost i vanjske webhook obavijesti.
• Upiti osjetljivi na performanse i poništavanje predmemorije.

Korisna je provjera jednostavna: ako bi novi razvojni inženjer prije izmjene morao pitati starijeg inženjera, ne bi se trebalo očekivati ni da pomoćnik umjetne inteligencije to pogodi.

Učinite pravila domene izvršivima gdje je to moguće

Najjača je dokumentacija često izvršiva. Metoda domene s jasnim nazivom, namjensko pravilo i usmjereni test pouzdanije komuniciraju od dugog komentara uz radnju kontrolera.

Razmotrite tijek rada narudžbe. Generička krajnja točka za ažuriranje poziva na slučajnu zloupotrebu jer su stvarna pravila skrivena u uvjetnoj logici. Mala domenska usluga čini dopušteni prijelaz očitim:

final class OrderWorkflow
{
    public function ship(Order $order): void
    {
        if (! $order->isPaid()) {
            throw new DomainException('Only paid orders can be shipped.');
        }

        if ($order->isCancelled()) {
            throw new DomainException('Cancelled orders cannot be shipped.');
        }

        $order->markAsShipped();
    }
}

Ovo nije samo čišći PHP. Umjetnoj inteligenciji koja pregledava ili proširuje sustav daje jasan rječnik: plaćeno, otkazano, poslano i uvjete koji ih povezuju. Dodajte testove koji utvrđuju rubne slučajeve i namjeravano ponašanje postat će teže slučajno izbrisati.

Koristite nazive koji nose poslovno značenje

Nazivi poput process(), updateStatus() i handle() tjeraju čitatelje da pregledaju implementaciju prije nego što mogu razumjeti namjeru. Dajte prednost nazivima koji otkrivaju pravilo: approveRefund(), reserveStock(), expireUnpaidInvoice() ili canAccessTenant().

Dobri nazivi ne zamjenjuju dizajn, ali smanjuju količinu konteksta koji umjetna inteligencija ili čovjek moraju ponovno izgraditi. Također čine pretraživanje vrijednijim: pretraživanje repozitorija za approveRefund postaje put do relevantnih pravila, a ne potraga kroz generičke rukovatelje.

Opišite ugovore na granicama sustava

Interni se kôd može razvijati zajedno. Granice ne mogu. API-ji, događaji, redovi čekanja, sheme baza podataka i integracije s trećim stranama trebaju eksplicitne ugovore jer se njihovi kvarovi obično pojavljuju daleko od svojih uzroka.

Za HTTP krajnju točku definirajte više od korisnog tereta uspješne putanje. Obuhvatite zahtjeve za autentikaciju, pravila validacije, oblike odgovora, slučajeve pogrešaka, ponašanje paginacije i očekivanja idempotentnosti. Za događaj navedite što ga je uzrokovalo, što njegova polja znače, može li isporuka biti duplicirana i što potrošači nikada ne smiju pretpostaviti.

Na primjer, rukovatelj webhook obavijesti o plaćanju trebao bi nedvosmisleno prikazati svoje ponašanje pri ponovnoj reprodukciji. Ako pružatelj može isporučiti isti događaj više puta, “obradi događaj plaćanja” nije dovoljno. Sustavu je potreban trajni ključ za uklanjanje duplikata i granica transakcije koja sprječava da ponovljena isporuka proizvede ponovljenu nuspojavu.

DB::transaction(function () use ($event) {
    if (WebhookReceipt::where('provider_event_id', $event->id)->exists()) {
        return;
    }

    WebhookReceipt::create(['provider_event_id' => $event->id]);

    $this->payments->applySettledEvent($event);
});

Točna implementacija razlikovat će se ovisno o okviru i bazi podataka, ali načelo je stabilno: napišite ugovor o dupliciranoj isporuci, a zatim osmislite i testirajte kôd tako da ga ispunjava. Pomoćnik umjetne inteligencije može produktivno raditi s tim ograničenjem; bez njega bi mogao “pojednostaviti” kôd i stvoriti suptilnu pogrešku u produkciji.

Dajte umjetnoj inteligenciji ograničen, relevantan kontekst

Više konteksta nije automatski bolji kontekst. Učitavanje cijelog repozitorija u tijek rada umjetne inteligencije može zakopati važno pravilo pod nepovezanim kodom okvira i zastarjelim modulima.

Umjesto toga, organizirajte kontekst oko zadatka. Za izmjenu otkazivanja računa navedite domenski model, pravila prijelaza, provjere pravila, relevantne migracije, API ugovor, testove i operativne aspekte. Evidenciju arhitektonskih odluka održavajte kratkom i konkretnom: objasnite odluku, njezin razlog i posljedicu njezina kršenja.

Smjernice na razini repozitorija također mogu pomoći. Sažet inženjerski dokument mogao bi uspostaviti konvencije poput:

• Kontroleri koordiniraju zahtjeve, ali nisu vlasnici poslovnih pravila.
• Svaka vanjska nuspojava mora biti sigurna za ponovni pokušaj ili izričito zaštićena od ponovnih pokušaja.
• Identifikatori zakupaca obvezni su u putanjama pristupa podacima.
• Promjene sheme zahtijevaju kompatibilan put uvođenja.
• Upiti osjetljivi na performanse moraju imati provjerljiv razlog za svoje indekse.

To nisu stilske preferencije kada štite ispravnost. To su tračnice koje održavaju generirane promjene usklađenima s arhitekturom.

Učinite vidljivom i logiku uvođenja

Skrivena logika nije ograničena na PHP klase. Slijedovi uvođenja često sadrže ključne pretpostavke: verzija aplikacije očekuje novi stupac, radnik reda čekanja mora se ponovno pokrenuti nakon izdanja ili se format ključa predmemorije mijenja tek nakon što stari radnici prestanu raditi.

Te pretpostavke predstavite u bilješkama o uvođenju, migracijama, provjerama stanja i automatizaciji. Dajte prednost promjenama baze podataka metodom proširi-pa-suži kada se stare i nove verzije aplikacije mogu preklapati. Dodajte stupac koji dopušta vrijednost null prije nego što ga učinite obveznim. Tijekom prijelaza po potrebi upisujte u oba prikaza. Uklonite stari put tek nakon što sustav više ne ovisi o njemu.

To promjenama uz pomoć umjetne inteligencije daje sigurniji okvir: ne “dodaj stupac”, nego “uvedi promjenu sheme kompatibilnu unatrag koja se može uvesti dok su prethodni radnici još aktivni.”

Pretvorite povratne informacije u trajno znanje

Svaki komentar u pregledu koji kaže “to ne funkcionira tako” signal je. Ako je vjerojatno da će se ista ispravka ponoviti, prenesite je u test, imenovanu apstrakciju, ugovor ili sažete smjernice blizu relevantne granice.

Dobit je veća od boljeg rezultata umjetne inteligencije. Novi se inženjeri brže uvode, pregledi postaju manje repetitivni, a odgovor na incidente manje ovisi o pronalaženju jedne osobe koja pamti zašto neobičan uvjet postoji.

Umjetna inteligencija ne otključava vašu bazu koda čitanjem više datoteka. Postaje istinski korisna kada važna logika vašeg sustava više nije skrivena. Učinite pravila eksplicitnima, provodite ih u kodu i testovima te svakoj promjeni dajte kontekst koji joj je potreban. Rezultat je softver kojem je lakše vjerovati — bilo da je sljedeći suradnik kolega, vi u budućnosti ili pomoćnik umjetne inteligencije.