92% programuotojų šiandien naudoja DI kodavimo įrankius, ir dauguma tikisi, kad jie pagerins bendradarbiavimą ir kodo kokybę. Tačiau eksperimentiniame tyrime patyrę programuotojai atliko užduotis net 19% lėčiau, kai DI pagalbą naudojo neapgalvotai. Problema buvo ne įrankis. Problema buvo tai, kaip juo naudotasi.
Šis atotrūkis tarp naudojimo mastų ir rezultatų yra visa istorija. Kodavimo agentai yra greiti ir gabūs, tačiau greitis padeda tik tada, kai kryptis yra teisinga. Toliau pateikiame, kas iš tiesų veikia, kas tyliai sunaikina spartą, ir praktinį planą, kaip iš kiekvienos sesijos išgauti daugiau.
Keturi dalykai, nuo kurių priklauso, ar agento sesija bus sėkminga
Prieš pereinant prie taktikų, verta suprasti pagrindinį dėsningumą:
Nedidelės, aiškiai apibrėžtos užduotys sprendžiamos greitai. Tiesmukas darbas, pavyzdžiui, API perdarymas, dažniausiai atliekamas per vieną ar dvi iteracijas.
Didelę projekto dalį aprėpiantys pakeitimai reikalauja kelių redagavimo raundų. Platūs pertvarkymai ir integracijos reikalauja pasikartojančio patikslinimo, nes paslėptas kontekstas ir ekosistemos ypatumai išryškėja tik darbo eigoje.
Suderinamumas yra svarbesnis nei generavimo greitis. Didžiausią stabdį spartai retai sukelia lėtai veikiantis DI. Tai dažniau neteisingai suprasti reikalavimai, trūkstamas kontekstas arba aplinkos nesutapimai.
Dokumentacija nėra pasirenkama. Atskiras dokumentacijos aplankas, aprašantis architektūrą, dalykinės srities modelius ir projekto ribojimus, pastebimai padidina, kaip tiksliai agentas laikosi numatyto tikslo.
Kas iš tiesų veikia
Siaura apimtis, aiškūs priėmimo kriterijai
Apibrėžkite vieną rezultatą ir aiškų atlikimo ženklą, pavyzdžiui, „visi testai žali”. Agentai veikia kur kas geriau, kai turi konkretų tikslą, nei kai gauna neapibrėžtą prašymą.
Kontekstu pagrįsti nurodymai
Technologijų rinkinys, versijų numeriai, failų kelias ir tikslus klaidos pranešimo tekstas turi reikšmės. Šios informacijos nepateikimas yra dažniausia priežastis, kodėl agentas pasiūlo nesuderinamą sintaksę arba sprendžia netinkamą problemą.
Pirmiausia planas, tada kodas
Paprašykite agento pirmiausia apibūdinti savo požiūrį, prieš rašant bet kokį kodą. Viena komanda pastebėjo, kad šis vienas įprotis pašalino apie 80% momentų, kai „DI pasimeta pusiaukelėje”, su kuriais anksčiau susidurdavo.
Minimalūs, atkuriami pavyzdžiai
Mažas, savarankiškas pavyzdys yra geresnis nei visos kodo bazės perdavimas. Agentui su juo lengviau samprotauti, o jums lengviau patikrinti rezultatą.
Sutartys ir tipai kaip apsauginiai turėklai
„TypeScript” tipai ir schemų validacija (tokie įrankiai kaip „Zod”) agentui suteikia papildomą bendravimo kanalą ir smarkiai sumažina išgalvotų laukų atsiradimą.
Laipsniškas pertvarkymas per sujungimo taškus
Įtraukite adapterio sluoksnį, kad senoji ir naujoji realizacijos galėtų egzistuoti kartu. Tai leidžia testuoti kiekvieną dalį atskirai, o ne statyti visą projektą ant vieno didelio pakeitimo.
Kas tyliai sunaikina spartą
Nesėkmės modeliai yra tokie pat nuoseklūs, kaip ir sėkmės modeliai:
Viską aprėpiantys nurodymai, kuriais vienu prašymu bandoma suprojektuoti, užkoduoti ir suplanuoti diegimą, lemia išplėstus, neaiškiai apibrėžtus atsakymus.
Visos kodo bazės perdavimas vienu kartu apsunkina darbą. Tai perkrauna DI konteksto langą ir pasiekia žetonų limitą gerokai anksčiau, nei suteikia naudingo signalo.
Pasenęs kodas arba tylios prielaidos apie tai, ką agentas „turėtų jau žinoti”, tiesiogiai lemia neteisingus pasiūlymus.
Tikrinimų praleidimas ir aklas pasitikėjimas DI pasiūlymais yra dažna priežastis, kodėl mažos klaidos virsta tolimesnėmis nesėkmėmis.
Didelės apimties pakeitimai be testų ar atkūrimo plano paprastą pakeitimą paverčia problema, kurią reikia visą atšaukti.
Dažniausias nusivylimas kyla dėl suderinamumo, ne greičio
Kai agento sesijos nepavyksta, retai dėl to, kad DI buvo lėtas. Dažniausiai pasikartojantys nusiskundimai yra: nuovargis dėl pakartotinių paprastų užduočių peržiūros reikalavimų, teoriškai teisingų atsakymų, netenkinančių tikslinės auditorijos poreikių, sprendimų priėmimo sunkumai renkantis tarp daug skirtingų pasiūlymų, neaiškios, sunkiai perprantamos klaidos ir testavimo duomenys, nukrypstantys nuo realių duomenų, netikėtai lemiantis vėlesnį klaidų atsiradimą.
Praktinis veiksmų planas
Prieš prašant pagalbos
Užrašykite tikslą vienu sakiniu. Nurodykite savo operacinę sistemą, numatytą projekto planą, kūrimo įrankius ir failų struktūrą. Įtraukite tikslų klaidos pranešimą arba dėklo (stack trace) informaciją. Apibrėžkite išmatuojamus priėmimo kriterijus prieš pradedant rašyti užklausą.
Formuluojant nurodymą agentui
Iš pradžių, paprašykite nurodyti veiksmų planą. Užduokite tikslinančius klausimus, pavyzdžiui, „ar naudojate „React Router”, ar „Next.js” nukreipimą?”. Paprašykite, kad pakeitimai būtų minimalūs ir apsiriboję konkrečiais failais, kad būtų įtrauktas patikrinimo žingsnis, ir kad būtų pažymėta rizika, šalutiniai efektai ir atkūrimo planas.
Pertvarkymas ir integracija
Sukurkite sąsajos arba adapterio sujungimo taškus, kurie atskiria seną ir naują kodą. Migruokite laipsniškai ir testuokite po kiekvienos dalies. Naudokite „TypeScript” sąsajas arba schemų bibliotekas aiškioms sutartims, rašykite sutarčių testus išorinėms integracijoms ir palaikykite trumpą pakeitimų žurnalą, kuriame fiksuojami padaryti kompromisai.
Testavimas ir kokybė
Parašykite testą prieš prašydami pataisymo. Stabilizuokite nepatikimai veikiančius testus, prieš leisdami agentui prisiliesti prie susijusio kodo. Naudokite aiškius modelius („Page Object Model”, „Given-When-Then”), kad tikslas būtų nedviprasmiškas, pridėkite papildomus testus sistemos sandūrose ir naudokite agentą, kad papildytumėte kraštutinių atvejų aprėptį, kai pagrindinė logika jau tvirta.
Dokumentacija
Prašykite konkrečių pavyzdžių: pavyzdinių užklausų ir atsakymų, trumpų kodo fragmentų. Projekto įgyvendinimo vadovus laikykite orientuotus į pagrindinį scenarijų. Atnaujinkite dokumentaciją tuo pačiu žingsniu kaip ir kodą, ir kiekvienos iteracijos gale paprašykite trumpos santraukos, kad perdavimas kitam žmogui vyktų sklandžiai.
Struktūrizuotas derinimo būdas: triažo kopėčios
Neaiškiems atvejams žingsniuokite per penkis etapus iš eilės: patikimai atkurkite klaidą, susiaurinkite jos vietą iki konkretaus failo ar funkcijos pagal dėklo informaciją, patikrinkite visas turimas užuominas (žurnalus, konsolės klaidas, tinklo informaciją), suvaldykite kintamuosius išjungdami funkcijas arba pakeisdami komponentus, kad izoliuotumėte priežastį, ir tada taisykite laipsniškai, tikrindami po kiekvieno mažo pakeitimo, o ne taikydami vieną didelį pataisymą.
Elkitės su agentu kaip su greitu, jaunesniuoju programuotoju
Dešimt minučių, skirtų tiksliam nurodymui parengti, ateityje sutaupo valandas painiavos ir derinimo. Geriausiai veikiantis mentalinis modelis: nepaprastai greitas, daug žinantis jaunesnysis programuotojas, kuriam vis tiek reikia aiškios krypties. Struktūrizuokite savo iteracijas apgalvotai, dirbkite mažais žingsniais, kuriuos jūs ar jūsų CI galite patikrinti, ir palikite vietos saugiam eksperimentavimui su funkcijų vėliavėlėmis, jungikliais ir kruopščiu žurnalų rašymu.
Nė vienas iš šių dalykų nereikalauja atsisakyti greičio. Jie reikalauja atsisakyti idėjos, kad vienas ilgas pokalbis stebuklingai pataikys į tikslą. Naudokite agentą, kad pagreitintumėte rutininį darbą ir gautumėte įkvėpimo, o patys valdykite kryptį ir priimkite sprendimus, kuriems reikia žmogaus vertinimo.
Jei jūsų komanda pradėjo naudoti DI siekiant pagreitinti savo darbą ir norėtų nepriklausomos nuomonės apie tai, kur procesas praranda laiką, susisiekite.