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

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

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

Архитектурата е хипотеза, а не стратегија за производ

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

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

Секоја нова граница создава работа: одделни распоредувања, договори, набљудливост, справување со неуспеси, дозволи, верзионирање и координација меѓу луѓето. Понекогаш таа работа е оправдана. Често, добро структурираната модуларна апликација е поодговорен избор.

Важно прашање не е: „Каква архитектура би препорачал експерт во апстрактен контекст?“ Туку: „Кој е наједноставниот систем што му овозможува на овој тим да учи, испорачува и работи безбедно во следната значајна фаза на производот?“

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

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

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

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

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

Прашања што вреди да се постават пред да се прифати дизајн

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

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

Преземете ги патеките на неуспех

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

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

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

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

Сопственоста значи да можете смирено и конкретно да одговорите: „Што правиме ако ова тргне наопаку?“

Користете ВИ за да го подобрите записот за одлуката

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

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

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

Ова е повредно отколку дизајнот да се прогласи за „најдобра практика“. Тоа ги прави компромисите видливи и му дава дозвола на следниот член на тимот да ја оспори одлуката кога условите ќе се променат.

Градете системи што повикуваат на одговорна промена

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

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

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

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

Предноста во кариерата е расудувањето

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

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

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

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