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

Колона во база на податоци со име status не му кажува на ВИ дали записите „архивирани“ смеат да се обноват. API-крајна точка не открива кои кориснички улоги можат да одобрат поврат на средства. Дефиниција на Docker-услуга не објаснува дека задача може да се изврши само откако плаќањето е порамнето. Тие правила постојат, но често се расфрлани низ контролери, класи за валидација, SQL-прашања, работници во редици, ознаки за функционалности и во главите на искусните инженери.

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

Вашата кодна база содржи повеќе од код

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

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

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

Почнете со одлуките што имаат последици

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

• Граници на дозволи и изолација на закупци.
• Движење на пари, наплата, залихи и неповратни операции.
• Машини на состојби со ограничени транзиции.
• Правила за задржување податоци, бришење и приватност.
• Задачи во заднина, повторни обиди, идемпотентност и надворешни webhook-и.
• Прашања чувствителни на перформанси и поништување на кешот.

Корисен тест е едноставен: ако на нов развивач би му требало да праша постар инженер пред да го промени тоа, не треба да се очекува ни ВИ-асистент да го погоди.

Направете ги доменските правила извршливи каде што е можно

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

Разгледајте работен тек за нарачка. Генеричка крајна точка за ажурирање поттикнува случајна злоупотреба, бидејќи вистинските правила се закопани во условна логика. Мала доменска услуга ја прави дозволената транзиција очигледна:

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();
    }
}

Ова не е само почист PHP. Му дава на ВИ што го прегледува или проширува системот јасен речник: платено, откажано, испратено и условите што ги поврзуваат. Додадете тестови што ги утврдуваат граничните случаи, и наменетото однесување станува потешко случајно да се избрише.

Користете имиња што носат деловно значење

Имиња како process(), updateStatus() и handle() ги принудуваат читателите да ја испитаат имплементацијата пред да можат да ја разберат намерата. Претпочитајте имиња што го откриваат правилото: approveRefund(), reserveStock(), expireUnpaidInvoice() или canAccessTenant().

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

Опишете договори на системските граници

Внатрешниот код може да еволуира заедно. Границите не можат. На API-ја, настани, редици, шеми на бази на податоци и интеграции со трети страни им требаат експлицитни договори, бидејќи нивните неуспеси имаат тенденција да се појават далеку од нивните причини.

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

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

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);
});

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

Дајте му на ВИ ограничен, релевантен контекст

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

Наместо тоа, организирајте го контекстот околу задача. За промена во откажување фактури, обезбедете го доменскиот модел, правилата за транзиција, проверките на политики, релевантните миграции, API-договорот, тестовите и оперативните аспекти. Чувајте ги записите за архитектонски одлуки кратки и конкретни: објаснете ја одлуката, причината за неа и последицата од нејзиното прекршување.

Насоките на ниво на складиште исто така можат да помогнат. Концизен инженерски документ може да воспостави конвенции како:

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

Овие не се стилски преференции кога ја штитат исправноста. Тие се шини што ги одржуваат генерираните промени усогласени со архитектурата.

Направете ја видлива и логиката за распоредување

Скриената логика не е ограничена на PHP-класи. Секвенците за распоредување често содржат критични претпоставки: верзијата на апликацијата очекува нова колона, работник во редица мора да се рестартира по издание или форматот на клучот за кеш се менува дури откако старите работници ќе исчезнат.

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

Ова им дава на промените потпомогнати од ВИ побезбедна рамка: не „додади колона“, туку „воведи промена на шемата компатибилна наназад што може да се распореди додека претходните работници сè уште се активни“.

Претворете ги повратните информации во трајно знаење

Секој коментар при преглед што вели „не функционира вака“ е сигнал. Ако истата исправка веројатно ќе се повтори, претворете ја во тест, именувана апстракција, договор или концизни насоки во близина на релевантната граница.

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

ВИ не ја отклучува вашата кодна база со читање повеќе датотеки. Станува навистина корисна кога важната логика на вашиот систем повеќе не е скриена. Направете ги правилата експлицитни, спроведете ги во код и тестови и дајте ѝ на секоја промена контекстот што ѝ е потребен. Резултатот е софтвер на кој полесно може да му се верува — без разлика дали следниот придонесувач е колега, вие во иднина или ВИ-асистент.