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

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

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

Брзината е вредна; расудувањето е работата

Генерираното решение може совршено да го реши наведениот проблем, а сепак да биде погрешен избор за производот. Разгледајте барање за копче „извези сè“. Нацрт со помош на ВИ може брзо да додаде endpoint, задача во заднина и врска за преземање. Инженерската работа не е завршена кога таа патека работи локално.

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

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

Сопственоста има повеќе слоеви

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

• Сопственост на проблемот: Може ли тимот да ги објасни корисничкиот проблем, очекуваниот исход и границите на барањето?
• Техничка сопственост: Дали имплементацијата се вклопува во постојниот систем, вклучувајќи ги моделите на податоци, зависностите, набљудливоста и однесувањето при неуспех?
• Сопственост на квалитетот: Дали се разгледани среќните патеки, граничните случаи, пристапноста, перформансите и безбедноста на соодветно ниво?
• Оперативна сопственост: Може ли тимот да открие проблем, да го разбере, безбедно да закрепне и да ги поддржи корисниците по објавувањето?
• Сопственост на учењето: Дали повратните информации од продукција ќе ја променат следната одлука на тимот, наместо да исчезнат во непрочитана контролна табла или белешка од ретроспектива?

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

Прегледувајте ги претпоставките, не само синтаксата

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

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

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

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

Направете ја верификацијата конкретна

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

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

На далечинските тимови им е потребна пишана сопственост

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

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

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

Заштитете ја одржливата испорака

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

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

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

Тимот и понатаму е производот

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

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