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

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

Вашето репозиториум е наставна програма во употреба

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

Започнете така што ќе го направите препорачаниот пристап лесен за пронаоѓање. Мал, добро одржуван пример за API крајна точка може да научи повеќе од општо упатство „следете ги најдобрите практики“. Тој може да покаже каде се врши валидацијата, како сервисот пријавува деловна грешка, каква структура на одговор добиваат клиентите и кој тест го покажува договореното однесување.

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

Направете го вистинскиот пример целосен

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

На пример, сервис може да ја изрази таа граница вака:

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

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

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

Запишете ги ограничувањата таму каде што се прават промените

Добрите насоки во репозиториумот се доволно конкретни за да влијаат врз одлуките. „Одржувајте ги API-јата безбедни“ е вредна, но нејасна насока. „Проверете дали автентицираниот корисник може да пристапи до побараната сметка пред да ги вратите нејзините фактури“ му дава на програмерот нешто конкретно за имплементација и преглед.

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

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

Користете ги тестовите за да го изразите однесувањето, а не само покриеноста

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

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

Дајте му на асистентот јасно ограничена задача

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

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

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

Поучете и за оперативната реалност

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

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

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