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

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

ВИ го засилува системот што веќе го имате

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

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

Чистата архитектура не значи максимална апстракција или совршено униформна кодна база. Таа значи дека важните одлуки се видливи. Развивачот — или развивачот со помош од ВИ — треба брзо да може да одговори на основните прашања: Каде се наоѓа ова правило? Кој е одговорен за него? Што зависи од него? Како знаеме дека промената е безбедна?

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

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

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

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

Користете граници што ги одразуваат вистинските концепти на производот

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

• Чувајте ги основните деловни правила блиску до концептот на производот што го уредуваат.
• Дајте им на операциите имиња што ја опишуваат намерата, како cancelSubscription наместо updateStatus.
• Нека зависностите течат кон стабилните правила, а не кон механизмите за испорака како HTTP-ракувачи или UI-компоненти.
• Документирајте ги неочигледните ограничувања покрај кодот и тестовите што ги спроведуваат.

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

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

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

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

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

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

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

it("does not cancel a subscription with a pending invoice", async () => {
  const subscription = createSubscription({ pendingInvoice: true });

  await expect(cancelSubscription(subscription)).rejects.toThrow(
    "A subscription with a pending invoice cannot be cancelled."
  );
});

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

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

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

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

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

• Дали ова го решава вистинскиот проблем на клиентот?
• Дали деловното правило се наоѓа во соодветната граница?
• Што се случува кога зависност не успее или внесот е нецелосен?
• Кое однесување намерно се зачувува?
• Може ли друг инженер да го одржува ова без да реконструира скриен контекст?

Користете ВИ како соработник, не како сопственик

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

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

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

Трајната предност е разбирлив софтвер

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

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