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

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

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

ВИ ја засилува архитектурата што веќе ја имате

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

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

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

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

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

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

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

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

• Дефинирајте сопственост. Наведете кој домен или услуга поседува деловно правило и неговите податоци.
• Документирајте ги границите. Опишете што преминува преку граница на модул, API, редица или база на податоци, и што не смее.
• Запишувајте ги значајните одлуки. Кратка белешка за одлука може да објасни зошто тимот избрал одреден пристап и каков компромис прифатил.
• Чувајте ги примерите блиску до кодот. Репрезентативен тест, барање или примерок од конфигурација често е покорисен од општо упатство.

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

Дизајнирајте за контролирана промена

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

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

Ова не значи дека на секоја апликација ѝ се потребни сложени граници меѓу услуги. Предвремената дистрибуција создава сопствена сложеност. Покорисното прашање е поедноставно: дали тимот може да промени една грижа без случајно да преработи три неповрзани?

Користете интерфејси за да ја откриете намерата

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

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

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

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

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

Практичната патека за испорака обично вклучува неколку слоеви на доверба:

1. Брзи автоматизирани проверки за форматирање, типови и очигледни регресии.
2. Фокусирани тестови за деловни правила и патеки на неуспех.
3. Интеграциски проверки за критични граници како плаќања, идентитет и трајно чување податоци.
4. Човечки преглед за намерата на производот, безбедносните импликации и одржливоста.
5. Набљудливост по издавањето, вклучувајќи значајни логови, метрики и прагови за предупредување.

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

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

Задржете ја човечката одговорност за одлуките

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

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

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

Развивачите треба да станат чувари на промената

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

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

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

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

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

Изградете системи што ја откриваат својата намера. Дајте им на важните правила јасни сопственици. Автоматизирајте проверки што обезбедуваат вистински докази. Зачувајте го контекстот зад значајните одлуки. Потоа користете ВИ како способен забрзувач во таа средина.

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