Archive for August, 2015

Aug 06 2015

Tarkvara riknemine

Published by Targo under Hea kood, Raha

Igaüks, kes on puutunud kokku mingi tarkvaraarendusega, on kuulnud või kogenud ka järgmist:

“See on mingi vana kood, mida keegi ei tunne, ära seda parem puutu.”

“See vana süsteem, millest keegi midagi ei mäleta. Mõnikord see ei tööta, siis me lihtsalt restardime seda.”

“Me vajutame siin neid nuppe kindas järjekorras, et asjad töötaks. Me ei tea, mis juhtub, kui teises järjekorras vajutada.”

Tegu on riknenud ehk legacy süsteemiga, pea igas organisatsioonis on mõni selline, vahel ka päris mitu. Kunagi on nende loomiseks kulunud palju raha, aega ja vaeva, aga nüüd tundub, et neist on rohkem tüli kui tulu. Kui uurida, mida teha, on arendajate lemmikvastuseks: “See vana asi on täielik jama ja kõik tuleks nullist ümber kirjutada!” Rahakoti käsutajatele see muidugi ei meeldi ja nii lükatakse “nullist ümber kirjutamist” edasi nii kaua kui võimalik. Eestis on suuremad süsteemid pea eksklusiivselt avalikus sektoris ning sagedaseks lahenduseks legacy probleemile on uue rahalaeva saabumine Euroopast.

Viimasel ajal on ümberkirjutamise idee aga jõudu kogunud ning Eesti avalik sektor soovib sisse viia lausa reegli, mis kohustaks süsteeme teatud aja tagant uuendama (otsi artiklist “no-legacy”).

Kas see ümberkirjutamine on aga parim tee? Kuidas süsteem üldse legacyks muutub? Ja mis elukas see legacy üldse on?

Minu kogemuses on tarkvara sisulise moraalse vananemise peamiseks sümptomiks hirm. Kas programmeerijad kardavad mingeid asju muuta? Kui neid muudatusi siiski tehakse, siis kas tellijad kardavad “kaardimaja efekti”? Hirmu mõõtmiseks on keeruline head joonlauda välja tuua, peamiselt on see hinnatav arendajate küsitlemise kaudu.

Aga miks arendajad kardavad? Sellepärast, et neil pole võimalik kergesti kontrollida, kas nende muudatused teevad midagi katki.

Regressioonide vältimiseks kasutatakse erinevates organisatsioonides mitmesuguseid meetodeid. Kõige tavalisem neist on, et tarkvara vastuvõtja (sageli mingi peakasutaja isikus) käib enda tavalised stsenaariumid läbi ja vaatab, et tema lemmiknupud paigast poleks nihkunud. Kui kontrollimiseks on mingid kirjapandud stsenaariumid ja fikseeritud protseduur, on tegu juba päris kõva sõnaga.

Sageli juhtub aga, et organisatsioonis polegi kedagi, kes suudaks kontrollida, kuidas asi peaks tegelikult töötama, sest “eit teadis, aga eit suri ära” ehk siis lahkus töölt, kaotas vastavad dokumendid ära või lihtsalt unustas. Siis ongi meil klassikaline riknenud tarkvara, kus me ei tea, mis töötab, mis mitte.

Rohkemat on väga raske teha, sest tarkvara regulaarne käsitsi kontrollimine on ausalt öeldes üsna nüri tegevus. Uncle Bob ütleb, et see on lausa amoraalne. Teoreetiline lahendus on mõistagi ilmne – las masin teeb igavat tööd, tema on rauast. Head automatiseeritud unit testid vähendavad süsteemiga seotud hirmu drastiliselt.

See on niivõrd oluline asjaolu, et ma kasutaks sellist definitsiooni: legacy on tarkvara, millel puuduvad efektiivsed unit testid.

Unit testide puudumine viib muudatusteni, mis pole verifitseeritud ja kasvatavad statistilist tõenäosust, et süsteemis on igasuguseid varjatud vigu, kuni lõpuks on olukord täielikult kontrolli alt väljunud.

Kui palju unit teste tegelikult kasutatakse? Minu kogemuses on siin tugev korrelatsioon sellega, kui palju tarkvarast hoolitakse. Oma isiklikud projektid on mul üsna hästi kaetud, mõni neist on 10+ aastat vana ja kannatab ikka üsna hästi arendamist ja täiendamist. Erasektoris on olukord laiguline – kui organisatsiooni eduks vajalikku tarkvara tehakse majas sees, saadakse üldiselt ka aru selle jätkusuutlikkuse hoidmise vajadusest.

Avalik sektor, kus mittehoolimise seemned on külvatud juba sügavale seadusandlusse, lepingutesse ja organisatsioonikultuuri, on vaeslapse osas. Unit testing nõuab ehk 20% ekstra aega (ja see aeg võidetakse tagasi juba esimese suurema muutuse realiseerimisel), kuid tarneahel, kus prioriteetideks on kiirus ja odavus, lõikab selle ekstra viiendiku armutult maha.

Ja nii olemegi olukorras, kus tarkvara on reaalselt riknenud juba esimesest päevast peale ning meil ei jää muud üle, kui peatselt uus süsteem tellida.

Poliitika, mis kohustab asutusi oma süsteeme regulaarselt uuendama, parandab mõnevõrra olukorda, kuid minu meelest ravime me sellega haiguse sümptomeid, mitte põhjust. Samuti on siin oht, et kui me kehtestame reegli, mille kohaselt tuleb iga 10 aasta tagant niikuinii uus tarkvara teha, siis kaob ka motivatsioon disainida tarkvara, mis peaks vastu nt 15 aastat. Viimane on hetkel küll puhtteoreetiline konstruktsioon, praegu oleks tore näha ka tarkvara, millega kasvõi pärast ametliku garantiiperioodi lõppu midagi teha on.

Minu endine tubli kolleeg ja praegune MKMi osakonnajuhataja Aet Rahe uurib, kuidas Eestis legacyga lood on ning milliste probleemidega asutused peamiselt kokku puutuvad. Tegu on tänuväärse tegevusega, sest minu teada pole sellist kaardistust Eestis varem tehtud.

Uurimuses on välja toodud mõned ideed, miks võiks organisatsioon soovida oma tarkvara vahetada. Kui häda käes, on need muidugi pädevad põhjused muudatuste tegemiseks, aga märksa parem oleks neid põhjusi ennetada. Siin väljavõte:

  • Liiga suured haldus- ja hoolduskulud

“Hoolduskulud” tähendab enamasti, et asjad lähevad katki, neid proovitakse parandada, aga edutult, parandatakse uuesti, mispeale lähevad hoopis teised asjad katki jne. Tegu on asjaga, mida unit testid definitsiooni kohaselt peaks parandama.

  • Ärilised või seadusandlikud muudatused

Ma eeldaksin, et kui organisatsioon ei hakka tegelema just mingi täiesti teistsuguse põhitegevusega, puudutab see muudatus siiski vaid väiksemat osa süsteemi loogikast. Ja kui tarkvara on disainitud korrektselt, s.t selle osad ei ole omavahel liiga tihedalt seotud, on võimalik neid osi ka üksteisest sõltumatult muuta.

  • Arhitektuuri keerukuse tõttu ei ole mõistlik enam süsteemi täiendada

Probleemi sõnastus ütleb ette ka vastuse – hea arhitektuur ei ole ülemääraselt keeruline.

  • Vendor lock-in

Vendor lock-in tähendab enamasti, et keegi peale vendori ei tea, kuidas tarkvara päriselt töötab (vendor teab vähemalt natuke) ja seetõttu ei julge keegi seal muudatusi teha. Kui meil on võimalik süsteemi tööd kergesti verifitseerida, kaob ka see oht.

  • Tehniliselt aegunud platvorm

Kui kasutatav tehnoloogia pidurdab süsteemi täiendamist, pole süsteemi osad suure tõenäosusega üksteisest piisavalt eraldatud. Kui kasutajaliideses pole eeldusi äriloogika reeglite kohta, ei takista keegi meil nt uut töövoomootorit kasutusele võtta. Kui äriloogikas pole eeldusi andmebaasistruktuuri kohta, ei takista keegi meil andmebaasi vahetamast. Kui andmebaasi pole sisse kirjutatud veebilehekülgede aadresse, pole ka mõne uue fancy UI toolkiti kasutuselevõtt probleemiks.

  • Puudub korrektne dokumentatsioon

Dokumentatsiooniga on see häda, et me tahaks mõõta tema eluiga kuudes ja aastates, aga reaalselt vananevad dokumendid päevade ja vahel isegi tundidega. Samas, kui meil on olemas korrektne töötavate automaattestide kogum, kajastab see definitsiooni kohaselt meie tarkvara tööd. Maha dokumentatsioon, elagu testid!

Kokkuvõttes:

  1. Tehes asju korralikult, saame enamikku probleemidest vältida ning tarkvara eluiga dramaatiliselt pikendada.
  2. Tarkvara korralikult tegemine ei ole eriti palju kallim (kui üldse).

Korralikkus jääb aga kahe asjaolu taha: lühiajaline mõtlemine ning teadmiste puudumine.

Lühiajaline mõtlemine on suuresti tingitud lepingute struktuurist. Kui ikka täitjale on loodud tugev motivatsioon teha asju võimalikult kiiresti ning pärast meid tulgu või veeuputus, on ka ennast hävitav kuidagi teisiti talitada.

Üks lahendus oleks siin pikemaajaliste raamkokkulepete kasutamine. Eestis on raamlepingud tavaliselt 3 aastat pikad, Soomes sageli nt 10-15 aastat. Teiseks saab paremini lahti kirjutada, millised on hooldusperioodi kohustused.

Teadmiste puudumine on probleemiks nii tellija kui täitja poolel. Kui võtame näiteks test-driven developmenti (TDD), siis ülikoolis seda ei õpetata ja ka enamik tööandjaid ei suuna oma töötajaid selles osas. Nii õpib enamik TDD praktiseerijaid kas kolleegidelt või internetist, enamasti pärast mitmeid põrumisi ja suurt frustratsiooni. Ma ise sain ka asjale alles siis pihta, kui olin kogenud asjatundjaga samasse tiimi sattunud.

Kusagilt tuleb aga siiski alustada. Minu meelest annaks kohustusliku best before tähtaja sisse seadmise asemel hoopis suurema efekti avaliku sektori tarkvaratellijate koolitamine selle osas, kuidas tarkvara rikneb ja kuidas seda välditakse. Hea oleks ka hangete tarvis näidisnõuete ette kirjutamine, kuidas tagada tarkvara paremat verifitseeritavust.

5 responses so far