6 Minutės
Linusas Torvaldsas, „Linux“ kūrėjas, atvirai sukritikavo vieną, esą Elono Musko naudojamą, samdymo ir darbo vertinimo metriką — kodų eilučių skaičiavimą. Išsamioje pokalbio metu „Linus Tech Tips" YouTube kanale Torvaldsas šią idėją pavadino ne tik klaidinga, bet ir atvirai „nekompetentinga“. Jo pareiškimai atgaivino diskusiją tarp programuotojų bendruomenių apie tai, kas iš tikrųjų lemia programinės įrangos įgūdžius ir produktyvumą.
Kodų eilučių skaičiavimas — pavojingas supaprastinimas
Interviu metu vedėjas paminėjo seną programavimo metriką: bendrą parašytų kodo eilučių skaičių. Pasirodė pranešimų, kad po to, kai Elonas Muskas perėmė „Twitter“ (dabar „X“), inžinieriams buvo liepta atspausdinti savo šaltinio failus — ir tie, kurių atspausdintų eilučių buvo mažiau, tariamai rizikavo netekti darbo. Torvaldsas nedvejojo: jis pavadino eilučių skaičiaus naudojimą inžinierių vertinimui „gryna nekompetencija“, pridūręs: „Kiekvienas, taip mąstantis, per kvailas dirbti technologijų įmonėje."
Toks aštrus vertinimas sustiprino diskusiją ir paliestą problemą: kiekybė nėra tas pats, kas kokybė. Vertinant produktyvumą pagal tai, kiek eilučių kas parašo, skatinama rašyti daug kliūčių, kurias sunku palaikyti — ilgus, neaiškius sprendimus, kurie didina klaidų skaičių ir techninį įsiskolinimą. Gerai suprojektuota programinė įranga dažnai veikia efektyviau su mažiau kodo: kodų ekonomija yra meistriškumo požymis, o ne tingumo ženklas. Tai svarbus aspektas programuotojų vertinime ir programavimo kokybės matavime.
Programuotojų reakcija: beveik vienbalsis nusivylimas
Visuose „Reddit" diskusijų skiltis ir kituose programuotojų forumuose bendruomenė daugiausia pritarė Torvaldsui. Komentarai svyravo nuo smagumo iki atviros pykčio: „Net pirmo kurso informatikos studentas supranta, kad eilučių skaičiavimas yra kvailiausia metrika.“ Tokių nuomonių banga aiškiai parodė, jog daugeliui specialistų LOC (lines of code) metrika atrodo ne tik netiksli, bet ir potencialiai žalinga.
Bendruomenė nurodo, kad toks požiūris skatina ištęstus, su daug pasikartojančio kodo sprendimus ir generuoja daugiau klaidų — priešingai nei įmonės tikisi, kai jos plečia produktus arba siekia platformos stabilumo. Diskusijoje pabrėžiama praktinė pusė: kada produkcija auga, svarbiau už eilutes yra patikimumas, testuojamumas ir galimybė greitai reaguoti į incidentus.
Pavyzdžiai, kurie tai iliustruoja
- Vienas glaustas ir gerai apgalvotas 100 eilučių algoritmas gali ženkliai pranokti 1 000 eilučių pleistro, kuris dubliuoja logiką ir slepia tikslą bei ketinimus.
- Refaktorizacija dažnai mažina eilučių skaičių, bet gerina aiškumą ir palaikomumą — ar griežta LOC politika nebaudžia būtent tokių gerų praktíkų?
- Automatinis kodo formatavimas, išsamūs logai ar išplėstinės dokumentacijos eilutės gali išpūsti eilučių skaičių, niekaip nepadidinant funkcionalumo ar patikimumo.
Įsivaizduokite, kad rašytojams būtų mokama už esė ilgį, o ne už aiškumą ar argumentų kokybę. Tas pats klaidingas mastymas pasireiškia ir tada, kai programuotojams atlyginama už apimtį, o ne už meistriškumą. Ypač didelėse komandose ar sparčiai augančiose kompanijose tokios klaidingos paskatos gali sukelti ilgalaikes problemas ir dideles išlaidas perlaikymui ir bugų taisymui.
Ką įmonės turėtų matuoti vietoje eilučių skaičiaus
Jeigu ne kodo eilutės, tai ką turėtų sekti vadovai ir techniniai lyderiai? Geresni, subalansuoti ir technologiškai prasmingi rodikliai orientuojasi į kokybę, pristatymo greitį ir stabilumą. Žemiau išvardijami metrikų tipai, kuriuos verta vertinti kartu su kontekstiniais komentarais ir praktiniais patarimais:
Kode peržiūros atsiliepimai (code review feedback). Kiek konstruktyvių komentarų kyla per peržiūras, kiek sprendimų priimta per diskusijas, ir ar peržiūros sumažina regresijų skaičių? Kokia yra peržiūrų kokybė — greiti „accept“ be paaiškinimo nėra geras ženklas.
Klaidų dažnis ir jų rimtumas (bug rates, severity). Ne tik klaidų skaičius, bet ir jų poveikis produktui, laikui, kurio reikia joms ištaisyti, ir pasikartojančių problemų analizė. Svarbu stebėti change failure rate (kokių pakeitimų metu kyla gedimai) ir mean time to recover (MTTR) — kiek laiko reikia atstatyti paslaugą po incidento.
Laikas nuo idėjos iki gyvo funkcionalumo (lead time for changes). Kiek laiko užtrunka nuo užduoties pradžios iki jos patalpinimo į gamybą? Trumpas lead time rodo efektyvias CI/CD praktikas, testavimo infrastruktūrą ir gerą darbo organizavimą.
Tesčių aprėptis ir testavimo kokybė (test coverage, test quality). Aukštas kiekinis aprėpties skaičius nėra garantas, jeigu testai nėra prasmingi. Vertinti reikia, kiek testai saugo kritines kelių funkcijų ir sistemos sąsajas, ar jie leidžia aptikti regresijas anksti.
Architektūrinis mąstymas ir sparti sprendimų priėmimo kokybė. Gebėjimas sukurti palaikomą architektūrą, prognozuoti didėjantį krūvį ir optimizuoti sąsajas tarp komponentų skiria patyrusį inžinierių nuo vidutinio. Vertinant tai galima įtraukti architektūrinių sprendimų dokumentaciją, dizaino peržiūras ir ilgalaikius veikimo rodiklius.
Komandinis darbas ir bendradarbiavimas. Soft skills svarbūs techninėms komandoms: kaip dažnai inžinierius dalijasi žiniomis, rašo aiškią dokumentaciją, moko kolegas ir sprendžia tikslus kartu su produkto savininkais. Tokie rodikliai mažina žinių vieneto riziką ir didina komandos produktyvumą.
Statiniai analizės įrankiai ir kodo kokybės rodikliai. Naudojant lint‘erius, statinius analizatorius ir metrikų įrankius (pavyzdžiui, ciklinę kompleksity, code smells, duplications) galima matuoti kodo rizikas, kurias sunku aptikti vien per eilučių skaičiavimą.
Praktinis patarimas techniniams vadovams: vietoje vienos paprastos metrikos geriau naudoti metrikų rinkinį (balanced scorecard), kuris apjungia techninę kokybę, verslo rezultatą ir žmogaus sugebėjimus. KPI turi skatinti palaikomumą, saugumą ir greitą reagavimą, o ne trumpalaikį maksimalų eilučių kiekį.
Taip pat svarbu, kad metrikų taikymas būtų protingas ir kontekstualus. Metrikos negali būti naudojamos kaip griežta „garsinė guma“ personalo skaičiavimui. Vertinimas privalo būti kontekstualus: skirtingi projektai turi skirtingus reikalavimus, o vienas rodiklis negali atspindėti visų kompetencijų. Tai ir buvo Torvaldso pagrindinė kritika — ne metrikos atskirai, o jos netinkamas ir kvailas naudojimas.
Galiausiai, technologijų įmonėms verta investuoti į procesus, kurie skatina apgalvotą dizainą: parengti kodo rašymo gaires, peržiūrų standartus, mokymus refaktorizacijos praktikai ir priemones, padedančias matuoti realų poveikį klientams, o ne formalius kiekybinius rodiklius.
Torvaldso kritika primena techniniams lyderiams: rinkitės metrikas, kurios skatina palaikomumą ir apgalvotą dizainą. Priešingu atveju rizikuojate skatinti elgseną, kuri didina techninį įsiskolinimą ir menkina produkto stabilumą — tai brangiai kainuojanti klaida bet kuriai technologijų įmonei.
Šaltinis: smarti
Palikite komentarą