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

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

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

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

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

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

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

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

Преминете од поттикнување-до-код кон намера-до-исход

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

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

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

• Вредност за корисникот: Што станува полесно, побрзо, побезбедно или појасно?
• Граница: Што намерно е надвор од опфатот на ова издание?
• Ризик: Што може да предизвика штета, забуна, губење податоци или прекумерен трошок?
• Доказ: Како тимот ќе знае дека функцијата работи како што е предвидено?
• Сопственост: Кој реагира кога функцијата ќе се расипе или ќе има потреба од ревизија?

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

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

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

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

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

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

Зачувајте ја трагата на расудувањето

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

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

Дизајнирајте работни текови за јасност при работа оддалечено

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

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

За дистрибуирани тимови, разгледајте лесна низа за испорака:

1. Опишете го проблемот на корисникот и најмалата вредна промена.
2. Наведете ги ограничувањата, вклучувајќи ги безбедноста, перформансите и оперативните очекувања.
3. Користете ВИ за да истражите опции за имплементација или да изработите нацрт за рутинска работа.
4. Потврдете го избраниот пристап преку тестови, преглед и проверки специфични за средината.
5. Пуштете го намерно, со начин за набљудување на однесувањето и промена на насоката ако е потребно.
6. Забележете што е научено пред да преминете на следната итерација.

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

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

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

Практично прашање пред пуштањето е: „Колку ќе нè чини да го одржуваме ова?“ Одговорот може да вклучува ново предупредување, оперативен прирачник, работен тек за поддршка или експлицитна одлука сè уште да не се автоматизира ризична патека. Понекогаш најдобрата продуктна одлука е помало издание со рачен чекор, бидејќи му помага на тимот да научи што навистина им треба на корисниците пред сложеноста да стане трајна.

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

Трајната предност е расудувањето

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

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