Iga tarkvaraprojekt kogub otseteid. Kiire parandus siin, kopeeritud-kleebitud funktsioon seal, “me refaktoreerime selle hiljem”, mida kunagi ei refaktoreerita. Eraldi võttes on igaüks neist kahjutu. Kokku moodustavad need selle, mida tööstuses nimetatakse tehniliseks võlaks — ning nagu rahaline võlg, koguneb ka intress.
Pärast aastakümmet klientidele tarkvara ehitamist ja hooldamist e-kaubanduse, FinTechi ja meedia valdkonnas oleme õppinud tehnilist võlga austama. Mitte kartma — vaid austama. Sest tõde on nüansirikkam kui “kogu võlg on halb.”
Mis tehniline võlg tegelikult maksab
Kõige ohtlikum asi tehnilise võla juures on see, et see on nähtamatu kõigile peale koodibaasis töötavate arendajate. Tegevjuht seda ei näe. Tootejuht seda ei tunneta. Kliendid ei märka seda — kuni nad märkavad.
Siin on see, mida oleme näinud võla päris projektides maksma minevat:
Aeglasem funktsioonide arendus. Funktsioon, mis peaks võtma nädala, võtab kolm, sest arendaja peab töötama ümber kõrbenud, sassis koodi. See on kõige levinum kulu ja kõige raskemini mõõdetav, sest see näib lihtsalt “arendus on aeglane.”
Rohkem vigu tootmises. Kui koodi on raske mõista, on seda raske ohutult muuta. Iga muudatus riskib millegi mitteseotu katkiajamisega. Oleme näinud projekte, kus 40% sprindiajast kulus regressioonide parandamisele, mitte uute funktsioonide ehitamisele.
Sisseelamise takistused. Uued arendajad liituvad meeskonnaga ja kulutavad nädalaid, üritades mõista, miks kood teeb seda, mida ta teeb. Dokumenteerimata töölahendused, ebajärjekindlad mustrid ning paikade kihid muudavad koodibaasi uustulnukatele vaenulikuks.
Kasutuselevõtu hirm. Kui meeskond kardab kasutusele võtta, sest “midagi võib katki minna,” on see võla sümptom. Oleme töötanud klientidega, kelle meeskonnad võtsid kasutusele kord kuus, sest iga väljalase oli hasartmäng. Nende konkurendid võtsid kasutusele iga päev.
Millal võlg on tegelikult tark valik
Siin on osa, mille enamik tehnilisi artikleid vahele jätab: mõnikord on võlg õige valik.
Kui CarBro vajas oma autoturu MVP turule toomist, tegime teadlikke kompromisse. Kasutasime lihtsamat andmebaasiskeemi, kui lõpptoode vajaks. Jätsime vahele mõned erandjuhtude käsitlused, mis mõjutasid vähem kui 1% kasutajatest. Valisime mitmel API lõpp-punktil kiiruse elegantsuse asemel.
See oli strateegiline võlg — võetud lahtiste silmadega, dokumenteeritud ja tagasimaksmiseks planeeritud. MVP käivitus tähtajaks. Ettevõte valideeris oma turuhüpoteesi. Ning me läksime järgmises etapis tagasi ja korrastasime koodi.
Peamine erinevus strateegilise ja juhusliku võla vahel:
- Strateegiline võlg on dokumenteeritud, ajaliselt piiritletud ning sellel on tagasimaksmisplaan.
- Juhuslik võlg koguneb vaikselt, sest meeskond kiirustab, on alaressursseeritud või puudub kogemus.
Hoiatusmärgid
Pärast aastaid koodibaaside pärimist teistelt meeskondadelt ja agentuuridelt oleme koostanud kontrollnimekirja ohtlike tehnilise võla tasemete tuvastamiseks:
Teste pole, või teste, mida keegi ei usalda. Kui testikomplekt võtab tundide kaupa aega, ebaõnnestub juhuslikult või jäetakse enne kasutuselevõttu vahele — võlg on sügav.
“Ainult üks inimene teab, kuidas see töötab.” Ühele arendajale koondunud teadmine on riski kordisti. Kui see inimene lahkub, muutub võlg kriisiks.
Kopeeritud-kleebitud kood kõikjal. Kui sama loogika eksisteerib viies kohas, peab iga veaparandus toimuma viis korda. Seda kunagi ei juhtu.
Koodibaas võitleb raamistikuga. Oleme näinud projekte, kus arendajad töötasid raamistiku tavade vastu, mitte nendega koos. Iga uuendus muutub lahinguks. Iga uue teegi integreerimine on valus.
Kasutuselevõtt võtab rohkem kui 15 minutit inimese tähelepanu. Kui kasutuselevõtt nõuab manuaalseid samme, SSH-ligipääsu ja ristis sõrmi, on infrastruktuuri võlg märkimisväärne.
Mida me selle osas teeme
Kui klient tuleb meie juurde koodibaasiga, mis on täis võlga — mis juhtub sagedamini, kui arvata võiks — siin on meie lähenemine:
Esiteks, hindame ausalt. Mitte iga võlaosa ei vaja parandamist. Osa elab koodis, mis harva muutub. Osa on funktsioonides, mis kaotatakse kasutuselt. Keskendume võlale, mis aktiivselt meeskonda aeglustab.
Teiseks, eraldame aega igal sprindil. Pühendame umbes 20% igast sprindist võla vähendamisele. Mitte eraldi “refaktoreerimissprindis,” mida kunagi ei toimu, vaid põimituna tavalisse funktsioonitöösse. Puudutad faili? Jäta see paremaks, kui see oli.
Kolmandaks, teeme selle nähtavaks. Jälgime võlaüksusi koos funktsioonide ja vigadega. Tooteomanik näeb neid. Klient näeb neid. Võla vähendamine ei ole salajane projekt — see on osa terve toote tarnimisest.
Neljandaks, ennetame uue võla teket. Koodiülevaatused, automaattestimine, järjekindlad mustrid ning ausad vestlused ajakavade üle. Odavaim võlg on võlg, mida sa kunagi ei võta.
Äriline vestlus
Kui oled asutaja või tooteomanik, kes seda loeb, siis siin on ebamugav tõde: su arendusmeeskond kannab tõenäoliselt rohkem võlga, kui nad sulle on öelnud. Mitte sellepärast, et nad seda varjaksid, vaid sellepärast, et neil ei ole head viisi selle selgitamiseks.
Küsi oma tehnikaliidrilt: “Kui sa saaksid kulutada kaks nädalat mistahes asjale koodibaasis, mis see oleks?” Vastus ütleb sulle, kus võlg elab. Ja sellega tegelemine kohe — isegi osaliselt — säästab sind kuude pärast.
Tehniline võlg ei ole tehniline probleem. See on äririsk. Ja nagu kõik riskid, on seda kõige odavam hallata enne, kui sellest saab kriis.
Codelive’is aitame meeskondadel ehitada uusi tooteid õigesti ning päästame projekte, mis läksid valesti. Kui su koodibaas sind aeglustab, räägime.