Повеќето тимови немаат проблем со разбирањето на ВИ. Тие имаат проблем со сопственоста.

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

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

Кодот е само еден дел од приказната

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

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

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

• Кој проблем го решава оваа компонента?
• Кои инваријанти мора да ги зачува оваа промена?
• Кој ја поседува одлуката кога барањата се нејасни?
• Кои тестови, контролни табли, прирачници за работа и контроли за пуштање се релевантни?
• Што е намерно привремено, а што е темелно?

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

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

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

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

Чувајте го важниот контекст блиску до работата

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

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

На секој извор на контекст му е потребен и јасен сопственик. „Сите ја поседуваат документацијата“ често значи дека никој нема време или овластување да реши противречности. Сопственоста не значи дека едно лице го пишува секој збор. Значи дека некој е одговорен материјалот да остане корисен и да одлучи кога е застарен.

Запишувајте ги одлуките на соодветното ниво

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

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

Намерно дизајнирајте ја јамката за човечки преглед

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

Практичната јамка за преглед има три фази:

1. Поставете ја рамката на задачата. Наведете го предвидениот исход, ограничувањата, засегнатите интерфејси и што не смее да се промени.
2. Проверете го предлогот. Прегледајте го генерираниот код како да доаѓа од нов член на тимот: следете ги влезовите и излезите, проверете ги патеките на грешки, преиспитајте ги претпоставките и споредете го со околните конвенции.
3. Потврдете го однесувањето. Извршете ги релевантните тестови, додадете тестови за променетото однесување и користете ги соодветните заштитни мерки при распоредување пред работата да ја сметате за завршена.

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

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

Направете ги генерираните промени лесни за оспорување

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

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

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

Користете ВИ за да го скратите растојанието меѓу прашањето и добро тестиранoто разбирање, а не меѓу задача и непреиспитана промена.

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

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

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

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

Сопственоста е конкурентската предност

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

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