Targo tarkvara

(Vaata esimest osa siin.)
Kõigepealt veelkord tarkvaratootmise põhiteoreemi sõnastus:

Vea parandamise hind kasvab aja möödudes. 

• Näide 5: Programmeerija Priit läheb kuuks ajaks puhkusele, aga klient nõuab, et programmi kohe-kohe paar muudatust tehtaks. Peeter teeb asja ära, annab üle, aga siis selgub, et mingid teised asjad on samal ajal katki läinud. Klient Kustav poetab mürgiseid märkusi, kus võrdleb programmeerijate tööd kaardimaja ehitamisega.
• Metoodiline lahendus 1: Iga programmeerija kirjutab koos koodiga ka piisava hulga automatiseeritud unit teste, mis tagavad igas olukorras keerulisema funktsionaalsuse toimimise. Kui kellelgi teisel on vaja programmis parandusi ja muudatusi teha, kontrollib ta, kas unit testid endiselt töötavad, ja tal on võimalik viga kohe parandada. Testide kirjutamine võtab muidugi lisaaega, aga see tasub end peaaegu alati ära, eriti kui on tegemist pikema projektiga, mille kallal töötab palju inimesi. Unit testingust asjana iseeneses ja pikemate/suuremate projektidega seotud iseärasustest kirjutan kunagi hiljem veel pikemalt.
• Metoodiline lahendus 2: ettevõte peaks koodi kirjutamisel kasutama ühtseid standardeid, mis võimaldavad inimestel üksteise koodi paremini mõista ja täiendada.

• Näide 6: Kustavil on kombeks alatasa mitmesuguseid väikesi täiendusi nõutada. Priit korraldab asjad tavaliselt kiiresti ära ja annab asjad üle. Kustav ei ole aga sellegipoolest rahul, kord crashib üks vorm, kord teine, ja talle jääb üleüldiselt kehv tunne. Samuti kulub Priidu ajast 30% esialgsete paranduste tegemisele ning 70% paranduste järel parandamisele.
• Metoodiline lahendus: defineerida hulk teste, mis kontrollivad programmi põhiomaduste korrektse töö. Erinevates organisatsioonides kutsutakse neid erinevalt, ma kasutan siin ja edaspidi nimetust Build Verification Test (BVT). Ilma BVT-de töötamiseta ei tee ükski programmeerija check-ini ja kliendile ei näe samuti kunagi midagi mis poleks sellest sõelast läbi käinud. BVT-de automatiseerimise korral on nende kasutamisele kuluv ajakulu mõõdetav minutites, tühine aeg võrreldes tühja töö ja vaimunärimisega, mis kaasneb paranduste parandustele paranduste tegemisega.
• Näide 7: aastal 1999 kontrollisid tuhanded ettevõtted kogu maailmas paaniliselt oma infosüsteeme, et ennetada Y2K probleemi. Tihti oli tegu süsteemidega, mille esialgsed loojad olid ammu pensionil ja hallihabemelistele Cobolihäkkeritele maksti ränka raha lihtsalt koodi ülevaatamise eest. Kui vigu leiti, oli tihti tegemist olukorraga, kus kood jooksis juba tuhandetel arvutitel üle maailma ja paranduste installeerimine põhjustas kalleid tööseisakuid. Sellest, kas Y2K oli tegelikult probleem või ei, on palju vaieldud, aga lugu illustreerib hästi asjaolu, et viga (konkreetses süsteemis), mille parandamine oleks aastal 1976 võtnud tunni, võttis nüüd tuhandeid inimtunde.

Loo üldine moraal on see, et tarkvarategemise igas etapis peab toimuma kvaliteedikontroll, mis tuleb teha võimalikult kiiresti, siis kui inimestel on asjad veel korralikult meeles, dokumentatsioon pole kusagile ära kadunud ega moraalselt vananenud. Kvaliteedikontrollist läbi lipsanud vead (olgu nad siis vead kliendi soovides, spetsifikatsioonis, disainis, koodis või kasutajajuhendis) põhjustavad üldjuhul selle, et järgmise etapi töö on tehtud valesti ning tuleb uuesti teha, mis ei mõju enamasti kellegi tujule hästi.
Tegelikult kõik väga elementaarne jutt ja paljud ehk küsivad, miks ma sellele ruumi raiskan: ühelt poolt on põhiteoreemi teadvustamine vajalik selleks, et mõista teemasid, millest hiljem juttu tuleb, teiseks aga toimub tarkvaratööstuses selle epideeminiline eiramine.

Miks põhiteoreemi eiratakse? Tihti on asi selles, et inimesed ei tea, millised metoodikad eksisteerivad asjade paremini korraldamiseks. Kui nad teavad, on nad tihti liiga laisad selleks, et neid ellu viia (ja peavad hiljem mitu korda rohkem tööd tegema, kui põhiteoreemi tagajärgede likvideerimiseks läheb).
Pahatihti juhtub ka, et inimesed leiavad, et nende töö on nii hea, et mingit kvaliteedikontrolli pole vajagi. Mul on olnud õnn töötada koos mõnede maailma tasemel inseneridega ning peamine, mis nende tegevuses silma torkab, on see, et nad panevad tohutut rõhku kvaliteedi tagamisele ning otsivad alati võimalusi selleks, et keegi nende tööd üle saaks vaadata. Aga sellest tuleb ka juba kord eraldi teema.

Lisalugemiseks veel põhiteoreeme: http://en.wikipedia.org/wiki/Fundamental_theorem

Trackback URI | Comments RSS