ВИ може да генерира убедлива функција од барање. Тоа не е исто што и разбирање на софтверот на кој му се приклучува.

Тешкиот дел од бекенд инженерството никогаш не бил брзо пишување код. Тој е зачувување на намерата низ граници: API договор, ограничување на база на податоци, политика за повторни обиди, околина за распоредување и негламурозното правило дека неуспешно плаќање не смее да стане две плаќања. Ако од ВИ асистент се очекува да прави трајни промени, му е потребен пристап до таа намера во форми што може да ги прегледува и за кои може да расудува.

Барањето е само влезот. Системот е контекстот.

Софтверот е повеќе од неговите изворни датотеки

Типична PHP услуга може да изгледа едноставно од перспектива на контролер: валидирај барање, повикај услуга, зачувај запис, врати JSON. Но значајното однесување може да биде распределено низ миграции на базата на податоци, работници во редици, конфигурација на околината, Docker дефиниции, правила за обратен прокси, поставки за набљудливост и договори со API на трети страни.

Разгледајте крајна точка за создавање нарачка. Локално веродостојна имплементација може да вметне ред за нарачка и да стави во редица е-пошта за потврда. Имплементација што го разбира системот поставува покорисни прашања: Дали барањето е идемпотентно? Дали залихата е резервирана пред да се потврди трансакцијата? Дали објавувањето во редицата може да не успее по запишувањето во базата на податоци? Дали повторен обид испраќа уште една е-пошта? Кои вредности за статус се валидни и каде се наметнуваат?

На тие прашања не може сигурно да се одговори со општо барање како „додај создавање нарачка“. Тие зависат од артефакти што ја прават архитектурата разбирлива.

Направете ги договорите видливи

Највредниот контекст обично не е повеќе проза. Тој е експлицитен договор близу до кодот што го имплементира. OpenAPI описи, JSON шеми, типизирани DTO-и, миграции на базата на податоци и интеграциски тестови секој открива различен дел од вистината на системот.

На пример, контролерот не треба тивко да одлучува што значи статусот на нарачка. Тоа правило припаѓа на доменска граница, претставена доследно во валидацијата, складирањето и одговорите.

enum OrderStatus: string
{
    case Pending = 'pending';
    case Paid = 'paid';
    case Cancelled = 'cancelled';
}

Оваа мала дефиниција не го решава деловниот тек, но ја отстранува двосмисленоста. ВИ што ја чита може да ги види дозволените вредности наместо да измисли состојба processing затоа што звучи разумно. Истиот принцип важи за одговори при грешка, формати за страницирање, правила за авторизација и payload-и за webhook.

Корисните договори треба да бидат извршливи каде што е можно. Документирана крајна точка е корисна; документирана крајна точка поткрепена со тестови е многу подоверлива. Кога документацијата и однесувањето не се согласуваат, тест-пакетот треба да го направи тоа несогласување видливо наместо да дозволи да стане племенско знаење.

Дизајнирајте граници што ја откриваат намерата

ВИ работи подобро во системи со јасни разграничувања, бидејќи и луѓето работат подобро во нив. Контролер што пристапува до неколку табели, форматира надворешно барање, применува правила за цени и испраќа задача остава премногу однесување имплицитно. Одвојувањето на тие одговорности создава места каде што намерата може да се именува и тестира.

• Контролерите ги претвораат HTTP аспектите во барања на апликацијата.
• Апликациските услуги координираат случај на употреба и неговата трансакциска граница.
• Доменскиот код ги поседува деловните правила и транзициите на состојбите.
• Адаптерите изолираат бази на податоци, редици, даватели на плаќања и друга инфраструктура.

Ова не е аргумент за церемонијални слоеви околу секој CRUD екран. Вистинската количина структура е онаа што спречува важните одлуки да протекуваат насекаде. Едноставно административно пребарување може да биде во ред како директно барање. Наплатата, распределбата на залиха и дозволите за сметки заслужуваат посилни граници бидејќи грешките имаат пошироки последици.

Дајте им на операциите имиња, не само имплементации

Метод именуван capturePayment() пренесува повеќе од генеричко save(). Тој сугерира неповратна надворешна акција, што веднаш треба да доведе до прашања за идемпотентност, истекување на време и записи за ревизија.

Имињата стануваат особено важни околу повторните обиди. Неуспесите на мрежата се нормални, а операцијата што може повторно да се обиде мора да биде дизајнирана така што нејзиното повторување е безбедно или видливо одбиено. Клучот за идемпотентност често е дел од договорот, а не изборна оптимизација.

public function createOrder(CreateOrderRequest $request): Order
{
    return $this->orders->findByIdempotencyKey($request->idempotencyKey)
        ?? $this->transaction->run(
            fn () => $this->createNewOrder($request)
        );
}

Деталите се разликуваат според рамката и слојот за перзистенција. Важната поента е дека базата на податоци исто така треба да ја наметне претпоставката за единственост. Самите проверки на ниво на апликација може да се натпреваруваат кога две идентични барања пристигнуваат истовремено.

Третирајте ја базата на податоци како извор на однесување

Шемата на базата на податоци често е најзанемарената форма на документација. Сепак, таа ѝ кажува на ВИ, и на следниот развивач, што системот е подготвен да прифати. Странските клучеви изразуваат односи. Уникатните ограничувања го штитат идентитетот. Колоните што не дозволуваат null ги разликуваат задолжителните од изборните податоци. Ограничувањата за проверка можат да заштитат едноставни инваријанти кога базата на податоци ги поддржува.

Миграциите треба да се прегледуваат како промени во однесувањето, а не само како инфраструктура за распоредување. Додавањето nullable колона обично е со низок ризик. Замена на вредност што ја користи индекс, пополнување наназад на милиони редови или заострување ограничување може да влијае на заклучувања, планови за барања и опции за враќање назад.

За поголеми промени, претпочитајте низа на проширување и стеснување:

1. Додадете промена на шемата што е компатибилна наназад.
2. Распоредете код што може да ги чита и старите и новите претставувања.
3. Пополнете наназад намерно, со следење на напредокот и справување со неуспеси.
4. Префрлете ги запишувачите и читачите откако податоците ќе станат стабилни.
5. Отстранете ја застарената патека во подоцнежно распоредување.

Овој образец им дава и на луѓето и на ВИ побезбеден пат низ промената. Тој го заменува „измени сè одеднаш“ со експлицитни меѓусостојби.

Контекстот мора да ја вклучува оперативната околина

Кодот што поминува локално сепак може да не успее во продукција бидејќи неговата околина цело време била дел од вистинската програма. Docker конфигурацијата, стандардните вредности на променливите на околината, здравствените проверки, командите за работниците и манифестите за распоредување треба да се одржуваат како првокласен код.

PHP апликацијата може да има потреба од одделни процеси за веб-барања и работа со редици. Ако Docker слика го документира само влезното место за веб, ВИ може да додаде класа за задача што никогаш не се обработува. Ако здравствена проверка само потврдува дека PHP се стартува, може да пријави успех додека апликацијата не може да стигне до својата база на податоци.

Оперативната документација треба да одговори на конкретни прашања: што го стартува секој процес, кои зависности мора да бидат достапни, која конфигурација е потребна и како изгледа безбедно враќање назад. Чувајте ги тајните надвор од примерите и репозиториумите, но направете ги потребните имиња на променливи и правилата за валидација видливи.

Изградете повратни јамки, не лажна самодоверба

Промените генерирани од ВИ ги заслужуваат истите заштити како промените генерирани од луѓе: форматирање, статичка анализа, насочени тестови, интеграциски тестови за важни граници и преглед во однос на вистинските критериуми за прифаќање. Целта не е да се бара исцрпно тестирање за секоја измена. Таа е да се постават најсилните проверки таму каде што промената преминува граница или може да ја наруши состојбата.

Добро pull барање ѝ дава на ВИ доволно повратни информации за да се поправи себеси. Неуспешен тест треба да го идентификува договорот што се прекршил. Тест за база на податоци треба да користи реалистични ограничувања. Тест за редица треба да провери што се случува кога испораката е одложена или дуплирана. Логовите и метриките треба да носат идентификатори на барање или задача што ги прават неуспесите во продукција проследливи.

Тука постои примамлива грешка: ВИ да се третира како побрз помлад развивач на кого само му требаат подолги барања. Таквото врамување ја пропушта можноста. Подобрата цел е да се изгради систем каде што точната патека е набљудлива, ограничена и тестлива.

Архитектурата станува барањето

Најдобриот софтвер за развој со помош на ВИ не е софтверот со најдолгата датотека со инструкции. Тој е софтвер чија намера е распределена низ искрени интерфејси, ограничувања, тестови, миграции и оперативни процедури.

Кога тие делови се согласуваат, ВИ може да даде корисен придонес бидејќи има нешто реално што може да го разбере. Кога се во конфликт или остануваат имплицитни, дури и елегантниот генериран код станува претпоставка. Изградете го системот така што неговите правила можат да се откријат, а потоа нека барањето укажува на тој систем. Така помошта станува инженерство наместо автоматско довршување.