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

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

Направете ја деловната одлука видлива

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

Започнете со одвојување на одлуката од механизмот што ја спроведува. На пример, правило за попуст може да ги прими потребните податоци и да врати резултат. Контролерот може да го обработи HTTP барањето, додека апликациска услуга го координира запишувањето на податоците и другите ефекти. Така програмерот или асистентот добива потесно прашање на кое треба да одговори: „Како треба да се промени ова правило?“ наместо „Што прави целиот овој обработувач на барања?“

final class DiscountPolicy
{
    public function discountFor(int $subtotalCents, bool $isMember): int
    {
        if (!$isMember || $subtotalCents < 10000) {
            return 0;
        }

        return intdiv($subtotalCents * 10, 100);
    }
}

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

Дајте им значајни договори на границите

Имињата помагаат, но договорите имаат поголема тежина. Метод наречен process() му кажува малку на читателот за тоа што прифаќа, што менува или како може да откаже. Метод со јасна намена, со експлицитни типови и документиран услов за откажување, им дава корисни ограничувања и на човечките рецензенти и на алатките со вештачка интелигенција.

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

Истото начело важи и внатре во апликацијата. Интерфејсот на репозиториумот треба јасно да покаже дали за непостоечки запис враќа null или фрла исклучок. Услугата што испраќа пораки треба јасно да ги прикаже своите несакани ефекти. Доследноста е поважна од усвојувањето на моментално популарна шема: предвидливите локални конвенции го олеснуваат следењето на промените.

Направете ги несаканите ефекти и патеките при откажување експлицитни

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

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

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

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

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

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

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

Рефакторирајте таму каде што се исплати

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

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

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