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

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

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

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

Дали поканата треба веднаш да резервира платено место или само по прифаќањето? Може ли администратор да ја повлече поканата откако вработениот почнал со регистрација? Дали извозот вклучува меко избришани записи? Кое ветување кон клиентот го одредува одговорот?

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

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

Градете контекст на границите каде што се носат одлуки

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

Почнете со продуктниот договор

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

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

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

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

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

Претворете го скриеното оперативно знаење во експлицитно однесување

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

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

Обезбедете му на ВИ добро осветлен работен простор

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

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

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

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

Сопственоста е заштитниот ров, а не обемот на кодот

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

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

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

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

Користете ја ВИ како тест на притисок за двосмисленоста

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

Пред да споите работа со помош на ВИ, прашајте:

1. Кое деловно правило го имплементира оваа промена и каде е наведено тоа правило?
2. Што се случува при повторни обиди, дуплирани барања, делумни неуспеси и одложени настани?
3. Кој тим или компонента ги поседува произлезените податоци и нивниот животен циклус?
4. Кој тест би паднал ако се промени однесувањето видливо за клиентот?
5. Како ќе откриеме и ќе се опоравиме од неуспех по распоредувањето?

Овие прашања не се бирократски товар. Тие се разликата меѓу забрзување на испораката и забрзување на преработката.

Градете го она што останува корисно откако ќе се генерира нацртот

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

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