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

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

Сопственоста е систем за учење

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

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

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

Направете ги границите очигледни пред да ги направите паметни

ВИ е особено ефикасна кога задачата има јасно место. „Додај поле во адресата за наплата“ е изводливо кога моделот на доменот, API-договорот, правилата за валидација и слојот за перзистенција имаат препознатливи одговорности. Станува ризично кога истиот поим се појавува на неколку места без очигледен единствен извор на вистина.

Техничките лидери треба да ги направат лесни за одговарање следниве прашања:

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

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

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

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

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

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

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

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

Тестовите се извршлива сопственост

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

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

На пример, тест наречен rejects_refund_when_original_payment_is_not_settled пренесува деловно ограничување. Тест наречен test_refund_7 не пренесува речиси ништо. ВИ може да ги генерира и двата; само едниот поддржува долгорочна сопственост.

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

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

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

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

1. Потврдете дека промената припаѓа во предложената компонента.
2. Проверете дека претпоставките за податоците, дозволите и начините на откажување се експлицитни.
3. Извршете релевантни тестови и проверете дали новите тестови го покриваат предвиденото однесување.
4. Разгледајте ги распоредувањето и враќањето назад, особено за промени во шемата или договорот.
5. Ажурирајте ги записите за одлуки или оперативните прирачници кога се менува оперативното однесување.

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

На оддалечените тимови им е потребно видливо управување

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

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

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

Градете системи што можат сами да се објаснат

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

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