Tehniline võlg: mis see on ja kuidas seda vähendada

Rakenduse alguses on uue funktsiooni lisamine kiire. Paari aasta pärast võtab sama suur muudatus kolm korda kauem ja pärast igat väljalaset tuleb parandada midagi, mida keegi ei puutunud. Arendaja ütleb „seda on keeruline muuta“ ja keegi ei oska täpselt selgitada, miks.

Sellel on nimi: tehniline võlg. See on kõigi nende otseteede summa, mis kunagi tehti, et midagi kiiremini valmis saada, ja mida hiljem korda ei tehtud. Nagu rahaline võlg, kogub ka see intressi: mida kauem see seisab, seda kallim on iga järgmine muudatus.

Kust tehniline võlg tuleb

Tehniline võlg ei ole tingimata halva töö märk. Sageli on see olnud teadlik ja mõistlik otsus: toode oli vaja turule saada enne konkurenti, tähtaeg oli kindel või polnud veel selge, mida kasutajad päriselt vajavad. Probleem tekib siis, kui otsetee jääb püsivaks lahenduseks.

Levinumad allikad:

• Uuendamata komponendid. Raamistik, teegid ja serveri tarkvara on mitu versiooni maas. Iga vahele jäänud uuendus teeb järgmise suuremaks ja riskantsemaks.
• Kopeeritud kood. Sama loogika on viies kohas veidi erinevalt. Parandus ühes kohas ei jõua teistesse.
• Puuduvad testid. Keegi ei saa enne väljalaset kontrollida, kas muudatus lõhkus midagi mujal.
• Dokumenteerimata otsused. Miks see tabel nii on üles ehitatud? Miks see funktsioon kutsub kolme teist? Vastus lahkus koos arendajaga.
• Ajutised lahendused. „Paneme praegu nii, teeme hiljem korda.“ Hiljem ei tulnud.

Kuidas tehnilist võlga ära tunda

Koodi ei pea ise lugema, et võlga märgata. Ärilised sümptomid on sageli selgemad:

• Hinnangud venivad: „see võtab kaks nädalat“ muutub kuueks.
• Vigu tuleb juurde kiiremini, kui neid parandatakse.
• Uus arendaja vajab kuid, enne kui julgeb midagi muuta.
• Teatud osa süsteemist ei taha keegi puutuda.
• Turvauuendusi ei paigaldata, sest „see võib midagi lõhkuda“.

Kui kolm või enam neist kehtib, on võlg tõenäoliselt juba suurem kui uue arenduse eelarve.

Kuidas võlga mõõta

Tehnilist võlga ei saa täpselt eurodes välja arvutada, aga selle saab kaardistada. Ülevaatusel vaatan läbi:

1. Komponentide vanuse. Millised raamistikud ja teegid on toeta, millistel on teadaolevaid turvaauke.
2. Riskikohad. Need osad, kus muudatused põhjustavad kõige rohkem vigu ja mida kõige sagedamini muudetakse. Seal tasub parandamine kõige rohkem ära.
3. Sõltuvused. Mis kutsub mida ja kas ühe osa vahetamine nõuab kümne teise muutmist.
4. Testide ja dokumentatsiooni seisu. Kui palju on süsteemist kontrollitav ilma käsitsi klõpsimata.

Tulemuseks on nimekiri, kus iga probleemi juures on risk, mõju ja hinnanguline töö. Sellest saab otsustada, mida teha kohe ja mis võib oodata. Kuidas ülevaatus täpsemalt käib, on lahti kirjutatud postituses tarkvara audit.

Kuidas võlga vähendada ilma äri seisma panemata

Kõige levinum viga on otsustada, et „kirjutame kogu asja ümber“. Töötav süsteem sisaldab aastate jooksul kogunenud ärireegleid, mida ükski spetsifikatsioon ei kirjelda. Ümberkirjutamisel tuleb need kõik uuesti avastada ja vahepeal peab vana süsteem ikka töötama. Millal ümberkirjutamine siiski tasub, on postituses vana tarkvara: uuendada või ehitada uuesti.

Mõistlikum on astmeline lähenemine:

• Alusta turvalisusest. Toeta komponendid ja teadaolevad turvaaugud enne kõike muud.
• Paranda seal, kus parasjagu töötad. Kui uus funktsioon puudutab mingit moodulit, korrasta see moodul samal ajal. Nii väheneb võlg seal, kus see päriselt maksab.
• Lisa testid enne muutmist. Riskantse osa ümber kõigepealt testid, siis muudatus. Nii on kohe näha, kui midagi läks katki.
• Vaheta osade kaupa. Vana moodul asendatakse uuega, kuni kõik osad on vahetatud. Iga sammu järel on sul töötav rakendus.
• Dokumenteeri jooksvalt. Iga otsus kirja, et järgmine inimene ei peaks otsast alustama.

Kui palju aega võla vähendamisele anda

Hea rusikareegel on hoida osa iga arendustsükli ajast korrastamise jaoks, mitte jätta seda „kunagi hiljem“ projektiks. Kui võlg on juba nii suur, et uusi funktsioone pole võimalik mõistliku ajaga lisada, on vaja eraldi moderniseerimise etappi. Siis tuleb mõnda aega teha rohkem korrastamist kui uut arendust.

Kokkuvõte

Tehniline võlg on normaalne, aga see ei tohi kasvada nähtamatult. Kaardista see, alusta suurima riskiga osadest ja vähenda seda samm-sammult, nii et äri ei pea ootama.

Kui su rakendus on jõudnud punkti, kus iga muudatus on kallis ja riskantne, vaata, kuidas ma teen tarkvara uuendamist ja edasiarendust, või kirjelda oma olukorda. Ütlen ausalt, kas rakendust tasub korrastada või on mõistlikum midagi uut ehitada.