Feel free to visit my blog post … LaylaQSacane

Unit teste võiks võrrelda ka kui kaitsekilbiga. Kui need on olemas, julgen kiiresti muudatusi sisse viia. Kui pole, siis tuleks enne muudatusi testid peale ehitada. See võib siis üsnagi palju aega võtta. Kui lähtekoodi pole, siis tõesti ei jää enamasti muud üle kui vana ära visata ja uus tellida. Väikeste tarkvaratükkide pole vast hullu, aga suurte süsteemide puhul on see kallis lõbu.

Lisaks sellele peaks mõtlema, kas meie äri saab lubada vigasid täis tarkvara ja seda, et iga uus järgnev arendus on aina aeganõudvam ja töömahukam. Kui palju vead maksma lähevad? Kas kaotame mõne tunni tööajas, kaotame kliendi või laseme põhja kogu äri?

Annar Meriranna kirjeldatud tellija soovile kohe vastu tulemine on osa kultuuris olevate indiviidide ellujäämistaktikast.

Mul on tunne, et osa moodsatest juhtimismeetoditest, näiteks scrum, koos juhtimise õpikutega optimeerub tegema asju kiiremini ja odavamalt, just meetodil “edasi tulgu või veeuptus”. Seda on juhtidele hea ja võimalik müüa, on tunne, et asjad lähevad kohe paremaks. Näiteks kõik tööaeg olgu kaetud kellegi teise poolt tehtud ticketitega. Vaadake, kui palju pie-charte on näiteks jira-s. Pie chart on minu jaoks lekkiv abstraktsioon, pooltõde. Kas probleem on mõõdetava effektiivsuse otsimine? Mida peaks mõõtma, kuidas mõõta 15a kestvusega lahendusi, tehtud ticketite järgi? Või peaks maksma 15a jooksul arendajatele “kliendi rahulolemise tasu”?
Ma ei ole lugenud lõpuni üht B.Gatesi top olevat raamatut inimkonna ressursside piiratusest, seal vist pakutakse lahenduseks kvaliteeti ja kestvust.
Siin meenub üks Tartu firma, kus vallandamiseks reastati inimesed tehtud ticketite järgi ritta ja kõige väiksema ticketite arvuga mees lendas. Kuigi töökaaslaste hinnangul tegi ta head tööd ja lendama oleks pidanud suure ticketite arvuga mees.

Legacy – osaliselt ka ootuste probleem.
Mõned päevad tagasi nägin üht maailma suurimatest majadest – Rumeenia parlamendihoonet. Seal oli väga palju marmorit, kallid käsitöövaibad jne. Giid vaikselt mainis, et selle maja ülalpidamiskulud on väga suured, valgustust piiratakse elektri kokkuhoiuks jne.

Asjade ostmine on lihtsam, kui olemasoleva stuffi vähendamine, kuid näiteks kodus tolmu koristamisel on asjade kogusel suur vahe. Mina vähendasin enda raamaturiiulit 3x. Uute asjade tegemine on lihtsam ja mõnusam, kui teha asju vähem. Mitte tegemine ning lihtsustamine vajab tugevat ja süstemaatilist mõtlemist, ebamugavat ja näiliselt tulemuseta pingutust.
Hoolimata lihtsusest ei tohiks teha lisavidinaid, jälle üks vidin, mis midagi näitab, mis vajab maksimaalselt 1-2a pärast uuesti tegemist, mille vajadus/funktsionaalsus/tulem ei ole robustselt täpne jne. Aga mida teha, kui keegi korra õrnalt vihjas, et oleks hea.

Lisaks unit testingule/automaattestimisele ka best practice jälgimine (mis iganes asjaga tegu on) ja dokumenteerimine! Dokumentatsiooni (lihtsal kujul!) ei saa vältida ka automaattestide korral, kui tahad, et su kood 10-20 aastat kasutuses oleks. Või ma ei ole viimaste trendidega lihtsalt kursis?

Probleem on tingitud ka sellest, et igale tellija soovile tullakse kohe vastu ja 99.99% juhtudest on probleemi lahenduseks koodi kirjutamine, mitte probleemi olemusest arusaamine. Kivi projektijuhtide ja konsultantide kapsaaeda, ja mina ca 10 aastat tagasi.

See oleks vajanud pisut rohkem lahti seletamist: “Tarkvara korralikult tegemine ei ole eriti palju kallim (kui üldse).”
Tegelikult maksab tarkvara korralikult tegemine (tunnihinnas) kordades rohkem, sest meeskond (mitte isik!), kes seda teha suudavad, küsivad ka kordades rohkem raha. Mis puudutab kvaliteedikontrolli, UAT-d ja auditit läbinud lõpptulemuse koguhinda, siis jah, ei ole enamasti palju kallim.

p.s. Olen ise tellinud tarkvara nii $8/h, kui €300/h küsiva meeskonna käest. Tulemused olid erinevad.

Never forget
“Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.”