Šta je tehnički dug?
Tehnički dug je koncept u razvoju softvera koji obuhvata “dodatan” napor potreban za održavanja baze koda. Potreba za tim dodatnim naporom se javlja usled korištenja raznih “prečica” u razvijanju aplikacija koje možda zaobilaze “best-practice” pristupe i industrijske standarde, ali u tom trenutku daju brze rezultate. Dakle govorimo o neefikasnim rešenjima koja nisu pokrivena testovima i zahtevaju vrlo specifično okruženje da bi sve radilo kako smo zamislili.
Šta su posledice gomilanja tehničkog duga?
Gomilanje tehničkog duga može prouzrokovati situaciju gde će naša aplikacija postati prevaziđena, jer će postati previše skupa za održavanje i nadogradnju. Kada kažem “skupa”, govorim o satnici programera u odnosu na potrebne promene. Kada je baza koda previše komplikovana i pati od lošeg dizajna, održavanje postaje skoro nemoguće - stari programeri postaju frustrirani i napuštaju projekat, dok novima treba značajno vreme da se upoznaju sa ovako “lošim” sistemom.
Jedno rešenje koje se tada često nameće je da se aplikacija piše iz početka ili zameni potpuno novim rešenjem. Zvuči kao dobar predlog ali je skoro nemoguće uraditi dok paralelno održavamo i nadograđujemo staru aplikaciju. Dok završimo novu koju smo gradili na osnovu stare, stara aplikacije više nije ono sa čime smo počeli - setimo se trke Ahila i kornjače…
Da li tehnički dug može stvarno da “ubije” projekat ili aplikaciju?
Tehnički dug možda zvuči apstraktno, i neki bi pomislili da “ako nešto radi svoj posao” ne može biti loše, ali to nije slučaj - navešću nekoliko poznatih aplikacija/sajtova koji su zamrli (delom) zbog nagomilanog tehničkog duga.
Možda najpoznatiji primer je MySpace. Njegova popularnost je postepeno opadala zbog nedostatka inovacije i loših performansi, a glavni uzrok ovoga je bio - pogodili ste - tehnički dug.
Neki od vas su možda čuli i za Friendster - on je bio nešto kao preteča Facebooka. Nažalost, rešenje je bilo loše izvedeno sa tehničke strane, skaliranje je zahtevalo previše napora i, u međuvremenu ga je Facebook u potpunosti istisnuo sa tržišta.
Tehnički dug je tim opasniji, što je aplikacija kompleksnija. Operativni sistem Windows Vista je kao jedan od najmanje uspešnih Windows sistema često kritikovan zbog zahtevnosti koju je iziskivao od hardvera i paralelno, loših performansi - poteškoće koje je Microsoft imao da odgovori na ove žalbe bile su uzrokovane velikim tehničkim dugom koji je nastao tokom izgradnje.
Dakle, u zavisnosti od veličine kompanije iza softvera, tehnički dug može da izazove sve od sitnih grešaka koje gube mušterije do velikih problema koji potope projekat, pa čak i čitav biznis model.
Najčešći uzroci stvaranja tehničkog duga su uvek prisutni.
Najčešći uzročnici se mogu svesti na nekoliko ključnih osobina, gotovo većine projekata na koje naiđemo.
1. Nedostatak planiranja. Iako svi ozbiljniji timovi makar tvrde da rade pod okriljem agilne metodologije, malo njih zapravo oštri svoje alate i koristi uvide koji se pojave u toku retrospektiva sprintova. Planiranje posla je “umetnost” i male, neizbežne greške u planiranju, a pogotovo one veće, nas teraju da skraćujemo i zaobilazimo procese koji su upravo tu da bismo proizvodili kvalitetniji kod.
2. Nedostatak refaktorisanja. Refaktorisanje koda je proces “prepisivanja” već postojećeg koda u bolje, lepše i čitkije verzije. Kada kažete onome ko finansira aplikaciju da ćete provesti nedelju ili dve prekucavajući nešto što već radi, šanse su da neće blagonaklono gledati na taj poduhvat. Ovaj nedostatak razumevanja za refaktoring - koji mora da se poput održavanje bašte, upražnjava redovno, često dovodi do progresivno lošijih rešenja.
3. Nedostatak testova. Boljka koja ide ruku pod ruku sa nedostatkom refaktorisanja. Pravilno postavljena “testna piramida” čini našu aplikaciju robusnijom - uvedene promene proveravaju automatizovani testovi, i ukoliko testova nema, napori da pobošljamo ili unapredimo bazu koda mogu dovesti do nepredviđenih grešaka i stvaranja dodatnog tehničkog duga. Nažalost, uvek je primamljivo odbaciti samo pisanje testova kao gubljenje vremena.
Kako sprečiti gomilanje tehničkog duga?
Pored uklanjanja navedenih nedostataka, možda najefektivniji način da se izbegne tehnički dug je uvođenje “kulture kvaliteta koda”. Ekipa koja je ponosna na ono što kuca će ispoštovati procese poput “Code review”-a, ubaciće u toku planiranja sprinta barem neko vreme posvećeno refaktorisanju postojećeg koda i generalno će svako sam da se trudi da napiše što bolje rešenje. “Kultura kvaliteta” je timski napor koji zahteva visok nivo osećaja individualne odgovornosti, ali je baš ta individualna odgovornost za priložen kod, jedini penicillin za loša rešenja. Čak i da smo stisnuti i gurnemo neko loše rešenje, u sledećem sprintu planiramo kako ćemo to da poboljšamo “za buduće generacije”.
Da li se može potpuno eliminisati tehnički dug?
Naravno, tehnički dug je gotovo nemoguće u potpunosti elminisati. Neka rešenja koja su idealna sada, neće biti optimalna nakon određenih biznis odluka i novih ciljeva naše aplikacije. Da bi aplikacija bila jak igrač na tržištu, potrebno je stalno prilagođavanje i čak i najbolje dizajnirana aplikacija će morati da menja kako pristupa određenim problemima.
Pažljivo planiranje, pokrivanje koda testovima i konstantno refaktorisanje su jedini načini da se prekomerno gomilanje tehničkog duga kontroliše. Iza svega toga mora da stoji “kultura kvaliteta” u samom timu koji proizvodi kod, jer će neka pravila morati povremeno da budu prekršena, ali je naša, programerska odgovornost, da bazu koda uskladimo sa standardima, a ne da loša rešenja guramo pod tepih.
3 komentara