Kad mazie kompromisi pārvēršas lielā haosā
Vai esat kādreiz saskārušies ar situāciju, kad šķietami sīks, ātrs risinājums pamazām pāraug milzīgā problēmā? Programmatūras izstrādē to sauc par “netīrajiem hakeriem” jeb “dirty hacks”, un tie ir kā mazas, baltas melīgās aizbildināšanās mūsu ikdienā. Sākumā nekas liels, bet, ja tās sāk krāties, sekas var būt nepatīkamas un dārgas.
Iedomājieties, ka draugs aicina brīvdienās doties uz kempingu, bet jums nav vēlmes. Tā vietā, lai teiktu “negribu”, jūs izdomājat stāstu par slimu radinieku. Ātri, vienkārši, problēma atrisināta. Līdzīgi rīkojas arī programmētāji, saskaroties ar negaidītu situāciju kodā: “Ātri pievienosim vēl vienu ‘if’ bloku, vai nokopēsim šo funkciju ar nelielām izmaiņām. Neviens nepamanīs!” Diemžēl, šie “nemanītie” risinājumi mēdz uzkrāties, veidojot to, ko tehnoloģiju pasaulē dēvē par tehnisko parādu.
Kas ir tehniskais parāds un kāpēc tas veidojas?
Tehniskais parāds ir kā kredīts, ko ņemam šodien, lai iegūtu ātrumu, bet kas nākotnē jāmaksā atpakaļ ar procentiem. Kā jau 1985. gadā atzīmēja Pīters Naurs, programma nav tikai koda rindiņas, bet gan kāda jēdziena (teorijas) iemiesojums. Kad kods aug un tiek mainīts, mainās arī sākotnējais jēdziens. Ja šīs izmaiņas ir organiskas un saskanīgas, tas ir kā piebūve mājai. Taču, ja tās ir haotiskas “piekombinēšanas”, sākotnējā ideja “izšķīst” un programma vairs nav loģisks veselums, bet gan atsevišķu, nesaistītu koda fragmentu kopums.
Kāpēc programmētāji vispār izvēlas “netīros hakerus”? Bieži vien tas notiek laika spiediena dēļ - ātrākais veids, kā dabūt funkciju strādājošu. Reizēm tas ir kā eksperiments, lai redzētu, vai konkrētā funkcionalitāte vispār ir nepieciešama vai kā tā attīstīsies. Katras mazākās izmaiņas dēļ pārstrādāt visu programmas arhitektūru nozīmētu “iemidzināt” tās attīstību. Tāpēc mazie kompromisi šķiet pieņemami. Sākumā.
Slēptās izmaksas: kad kods sāk “brūkt kopā”
Kādu dienu radinieku meli atklājas, un tas ir nepatīkami. Ar programmatūru ir līdzīgi - “netīrās aizbildināšanās” beigās noved pie nestabilas un grūti uzturamas sistēmas. Programmas izmaiņas kļūst par azartspēli: vai viss turpinās strādāt, vai arī sabruks? Ja kods un sākotnējais koncepts vairs neatbilst, katra jauna funkcija vai labojums ir daudz sarežģītāks un riskantāks. Slēptās izmaksas pieaug - garākas izstrādes laiks, biežākas kļūdas, neapmierināti klienti un izstrādātāji.
Piemēram, uzņēmums var saskarties ar situāciju, ka jaunu funkciju ieviešana, kas agrāk prasīja dienas, tagad aizņem nedēļas. Kļūdu labošana, kas bija minūšu jautājums, tagad prasa stundas vai pat dienas, jo neviens vairs īsti nesaprot, kā “sakompilētais” kods darbojas kopumā. Tie ir tie brīži, kad sistēma “apstājas” trīsreiz nedēļā, un uzņēmums zaudē gan naudu, gan reputāciju.
Kā izvairīties no “netīrajām aizbildināšanām” kodā?
Vai tas nozīmē, ka jāizvairās no jebkādiem ātriem risinājumiem? Ne gluži. Svarīgāk ir apzināties, ka tie ir pagaidu risinājumi un rīkoties atbildīgi. Lūk, daži veidi, kā mazināt tehnisko parādu:
- Detalizēti komentāri: Katram “dirty hack” ir jābūt izsmeļošam komentāram kodā (nevis atsevišķā dokumentācijā!). Tam jāizskaidro, kāda funkcionalitāte bija nepieciešama, kāpēc tika izvēlēts šis risinājums, nevis “tīrāks”, un kādas problēmas tas var radīt nākotnē.
- Atpazīt signālus: Ja komentāri sāk aizņemt pusi no ekrāna, tas ir nepārprotams signāls, ka pienācis laiks refaktorēt jeb pārrakstīt koda daļu, lai to saskaņotu ar jauno konceptu.
- Regulāra “tīrīšana”: Tāpat kā ikdienā mēs sakārtojam savas mājas, programmatūras kods ir regulāri jārevī un jāuztur. Šis process var būt sāpīgs un laikietilpīgs, bet tas ir kā atdot kredītu, lai varētu dzīvot bez stresa.
Šo “parāda atmaksu” var uztvert arī kā iespēju. Prasības ir attīstījušās, un programmai ir jāpielāgojas. Pārdomāta refaktorizācija ne tikai novērš esošās problēmas, bet arī padara programmu izturīgāku pret nākotnes izmaiņām.
Komandas sadarbība: kad tīrīt “virtuvi”?
Jautājums par to, kad tieši sākt “tīrīšanu”, ir sarežģīts. Tas ir kā “kopmītnes problēma” - katram ir sava sajūta par kārtību. Vienam drupačas uz galda jau šķiet katastrofa, citam netīri trauki izlietnē ir ikdiena. Izstrādātāji bieži vien jūt, kad programmatūra vairs nesniedz prieku, bet vadība redz tikai “divus mēnešus bez jaunām funkcijām”.
Šādos gadījumos ir svarīgi veidot uzticību un savstarpēju sapratni. Ja pieredzējusi izstrādes komanda vienbalsīgi paziņo, ka kods brūk kopā, tam ir iemesls. Un, ja vadībai ir svarīgi līdz noteiktam datumam ieviest kādu funkciju, tad reizēm koda kvalitāte var pagaidīt. Svarīgākais ir nevis izvairīties no “melīgām aizbildināšanās”, bet gan spēt atpazīt un risināt problēmu, tiklīdz tā rodas. Jo ilgāk mēs to atliekam, jo dārgāk tas izmaksās.
Kādu pieeju “netīro hakeru” apkarošanā izvēlēsies tava komanda?
Iezīmē tekstu un spied ziņot par kļūdu.
