Google DORA tyrimas: DI kode vertę reikia matuoti, ne jausti
·
DI kode vertė šiandien nėra vien techninė naujiena. Čia yra klausimas, kuris ateina iki vadovo stalo: ką leisime DI daryti praktiškai, kiek tai kainuos ir kas patikrins rezultatą?
Google Cloud DORA tyrimo žinutė man skamba labai praktiškai: DI kode reikia matuoti, o ne jausti. Nes jausmas po gero įrankio demo dažnai būna kaip po kavos – energijos daug, bet darbas nebūtinai padarytas.
Man tokiose istorijose visada įsijungia tas mažas balsas galvoje: gerai, gražu, bet kur čia realus darbas? Ne demonstracija scenoje, ne gražus paveiksliukas, o pirmadienio rytas komandoje, kai kažkas turi priimti sprendimą.
KAS NUTIKO
Google Cloud aprašė, kaip vertinti generatyvinio DI naudą programinės įrangos kūrime. Akcentas krenta ne tik į greitį, bet į platesnį vaizdą: kokybę, pristatymo ritmą, komandų darbą ir realią verslo vertę.
Jei kūrėjas su DI parašo kodą greičiau, tai dar nereiškia, kad įmonė laimėjo. Gal testų daugiau, gal klaidų daugiau, gal peržiūra užtrunka ilgiau. Čia prasideda nematoma sąskaita.
KODĖL VERTA SUSTOTI
DI įrankiai keičia kūrėjų darbą, bet vertė atsiranda tik tada, kai komanda matuoja visą srautą: nuo idėjos iki veikiančio produkto, o ne vien sugeneruotų eilučių skaičių.
DI rinka dabar primena treniruotę, kur visi nori iš karto užsidėti sunkiausias lopetėles baseine. Tik paskui paaiškėja, kad technika dar byra, kvėpavimas ne vietoje, o rankos pavargsta greičiau nei ego spėja pasiteisinti.
KĄ TAI REIŠKIA VERSLUI
Vadovams tai svarbu, nes DI programavime lengva nusipirkti įrankį ir galvoti, kad produktyvumas jau pakilo. Reikia žiūrėti, ar greičiau išleidžiami naudingi pakeitimai ir ar mažėja klaidų kaina.
- matuoti pristatymo laiką nuo užduoties iki paleidimo
- stebėti klaidų kiekį po paleidimo
- vertinti kodo peržiūros apkrovą
- lyginti komandas pagal procesą, ne pagal eilučių kiekį
Paimkite vieną komandą ir vieną mėnesį matuokite tris rodiklius: kiek užduočių baigta, kiek jų grįžo taisymui ir kiek laiko užtruko peržiūra.
KUR GALI SKAUDĖTI
Rizika – skatinti greitį be kokybės. Tada DI tampa ne pagalbininku, o greitesniu būdu prisigaminti techninės skolos.
Blogiausia klaida čia dažnai ne techninė. Blogiausia klaida yra tyli. Įrankis įjungtas, visi galvoja, kad kažkas prižiūri, o iš tikro niekas nežino, kas atsakingas už paskutinį sprendimą.
KĄ PASIDARYTI ŠIĄ SAVAITĘ
Susitarkite dėl trijų DI produktyvumo rodiklių prieš perkant dar vieną įrankį. Jei rodiklių nėra, vėliau ginčysitės nuomonėmis.
Šaltinis: Google Cloud.
DUK
Kas yra DORA?
Tai tyrimų kryptis ir metrikų rinkinys, padedantis vertinti programinės įrangos kūrimo našumą.
Kaip DI keičia programavimą?
Jis gali greitinti rašymą, paiešką ir analizę, bet poveikį reikia matuoti per visą procesą.
Kokia metrika pavojinga?
Vien sugeneruotų kodo eilučių skaičius, nes jis nieko nepasako apie kokybę.
Jei DI norite naudoti ne dėl mados, pradėkite nuo vieno proceso. Susirašykite žingsnius, paskirkite žmogų peržiūrai ir tik tada junkite įrankius. Daugiau praktinių DI taikymo pavyzdžių rasite MasterSprint.
