Tehniline võlg veebiprojektis — kuidas see tekib ja mida maksab
🎧 Kuula kõiki artikleid järjest
Iga veebiprojekt kogub aja jooksul tehnilist võlga. Küsimus ei ole selles, kas võlg tekib, vaid selles, kas seda hallatakse teadlikult või lastakse sellel kasvada seni, kuni see hakkab arengut pidurdama.
Tehnilise võla mõiste pärineb tarkvaraarendusest ja kasutab võrdlust finantsmaailmaga. Nagu rahaline võlg, tuleb ka tehniline võlg mingil hetkel tagasi maksta. Mida kauem seda edasi lükata, seda suuremaks muutub selle "intress" ehk lisakulu.
Paljud organisatsioonid märkavad tehnilist võlga alles siis, kui veebiplatvorm muutub aeglaseks, uuendused ei õnnestu või iga uus arendus võtab oodatust rohkem aega.
Mis on tehniline võlg?
Tehniline võlg on vahe selle vahel, kuidas süsteem praegu töötab, ja kuidas see võiks olla ehitatud tänaste teadmiste, nõuete või standardite järgi.
See võib tekkida mitmel põhjusel:
- kiire tähtaeg nõudis ajutist lahendust;
- projektile ei olnud algselt planeeritud nii suurt mahtu;
- tehnoloogia või ärivajadused muutusid;
- süsteemi ei ole regulaarselt uuendatud;
- dokumentatsioon jäi puudulikuks;
- testid jäid kirjutamata.
Oluline on mõista, et tehniline võlg ei tähenda automaatselt halba arendust.
Mõnikord on teadlik kompromiss täiesti mõistlik otsus. Probleem tekib siis, kui kompromissidest saavad püsilahendused.
Kuidas tehniline võlg välja paistab?
Tehniline võlg ei ole tavaliselt nähtav kasutajale.
Kasutaja näeb töötavat veebilehte.
Probleemid ilmnevad meeskonnale.
Muudatused muutuvad aeglaseks
Lihtne funktsionaalsus, mille lisamine peaks võtma paar tundi, võtab mitu päeva.
Põhjuseks ei ole töö ise, vaid vajadus mõista olemasolevat süsteemi, kontrollida kõrvalmõjusid ja parandada vanu sõltuvusi.
Uuendused muutuvad keeruliseks
Drupal core'i või mooduli uuendus peaks olema rutiinne tegevus.
Kui süsteem on aastaid uuendamata, võib isegi väike versioonitõus nõuda:
- PHP uuendamist;
- moodulite väljavahetamist;
- kohandatud koodi parandamist;
- migratsioonitöid.
Kood, mida keegi ei julge puudutada
Peaaegu igas vanemas projektis leidub kohti, mille kohta öeldakse:
> "Ära seda osa muuda, muidu võib midagi katki minna."
See on üks selgemaid tehnilise võla tunnuseid.
Kui süsteemi käitumist ei mõisteta või ei suudeta turvaliselt muuta, hakkab areng aeglustuma.
Testide puudumine
Kui puuduvad automaattestid, ei ole võimalik kiiresti kontrollida, kas muudatus midagi rikkus.
Iga uus arendus muutub riskantsemaks.
See suurendab käsitsi testimise mahtu ja vähendab kindlustunnet uuenduste tegemisel.
Kuidas tehniline võlg koguneb?
Tehniline võlg ei teki tavaliselt ühe suure otsusega.
See koguneb väikeste sammudena:
- üks kiire erilahendus;
- üks dokumenteerimata muudatus;
- üks edasi lükatud uuendus;
- üks moodul, mida enam ei hooldata;
- üks test, mida "praegu pole aega kirjutada".
Iga selline otsus võib olla eraldi vaadates mõistlik.
Probleem tekib siis, kui neid koguneb kümneid või sadu.
Mida tehniline võlg maksab?
Tehnilise võla hind ei kajastu tavaliselt ühel arvel.
See väljendub:
- pikemates arendusaegades;
- kallimates uuendustes;
- sagedamates vigades;
- suuremates turvariskides;
- keerulisemates partnerivahetustes.
Näiteks võib kolm aastat uuendamata Drupal-sait vajada mitte lihtsalt kolme aasta jagu uuendusi, vaid osalist ümbertegemist.
Selle aja jooksul võivad olla muutunud:
- Drupal core;
- PHP versioon;
- moodulite sõltuvused;
- serverikeskkond;
- ligipääsetavusnõuded;
- turvastandardid.
Seetõttu muutub iga edasi lükatud aasta tavaliselt kallimaks kui eelmine.
Kuidas tehnilist võlga hallata?
Tehnilist võlga ei likvideerita tavaliselt ühe projektiga.
Tõhusam on seda vähendada järjepidevalt.
Tee uuendusi regulaarselt
Regulaarne hooldus hoiab sõltuvused ajakohased ja vähendab olukordi, kus tuleb teha suur ühekordne hüpe.
Dokumenteeri olulised otsused
Kui projektis tehakse erilahendus või tehniline kompromiss, peaks selle põhjus olema kirjas.
See aitab tulevastel arendajatel mõista, miks midagi ehitati just sellisel viisil.
Lisa teste järk-järgult
Kõiki teste ei pea kirjutama korraga.
Oluline on, et kriitilised töövood saaksid aja jooksul automaatse katvuse.
Kaardista võlg nähtavaks
Kõige raskem on hallata probleemi, mida keegi ei näe.
Tehnilised riskid, vananenud sõltuvused ja probleemsed komponendid võiksid olla dokumenteeritud samamoodi nagu ärilised riskid.
Millal tasub teha audit?
Kui projektis esineb mitu järgmistest sümptomitest:
- uuendusi pole tehtud üle aasta;
- puudub ülevaade moodulitest ja sõltuvustest;
- koodi ei hoita Gitis;
- testid puuduvad;
- partneri vahetus on plaanis;
- arenduse tempo on märgatavalt aeglustunud;
siis tasub teha tehniline audit.
Audit ei kõrvalda tehnilist võlga, kuid aitab selle nähtavaks teha ja prioriteedid paika panna.
Kokkuvõte
Tehniline võlg ei ole märk läbikukkunud projektist.
See on loomulik kõrvalnähtus igas pikaealises veebisüsteemis.
Oluline erinevus on selles, kas võlga hallatakse teadlikult või ignoreeritakse seni, kuni see muutub probleemiks.
Regulaarsed uuendused, dokumentatsioon, testid ja tehniline ülevaatus aitavad hoida tehnilise võla kontrolli all. Nii on veebiplatvorm turvalisem, arendatav ja odavam pidada ka mitme aasta pärast.
Kui olemasoleva Drupal-projekti seis ei ole selge, aitab audit ja testimine kaardistada peamised riskid ning hinnata, kui palju tehnilist võlga süsteemi on kogunenud.
Vajad Drupal abi?
Kui artikkel puudutab sinu olukorda, ei pea kõike lõpuni lugema. Sinuga suhtleb päris inimene ja aitab järgmise sammuni jõuda.