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

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

Деловната интуиција е проблем на дизајнот на системот

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

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

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

Почнете од одлуките, не од документите

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

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

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

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

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

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

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

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

Користете ги тестовите како извршлив деловен јазик

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

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

Забележете го „зошто“ зад необичниот код

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

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

Дизајнирајте го работниот тек со ВИ околу граници

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

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

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

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

Сопственоста го претвора контекстот во живо средство

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

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

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

Мерете ја корисноста според квалитетот на испораката

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

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

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