Računalniški žargon z izrazom »špageti koda« slikovito opiše slabo načrtovano, izdelano in pogosto tudi neustrezno programsko opremo, ki je hkrati tudi izjemno draga za vzdrževanje. Pregovor pravi, da riba pri glavi smrdi. In res, programerjev ne moremo kriviti za vse tegobe slovenske računalniške industrije, močno odvisne od zaradi gospodarske krize presihajoče informatizacije slovenske javne uprave. Če bi bila Slovenija čudežna dežela s tisočimi majhnimi in srednjimi podjetji, ki bi proizvajala programsko opremo, res ne bi smeli imeti težav s prodorom svojih rešitev na svetovni trg programske opreme. Na splošno sicer ne moremo reči, da tudi v Sloveniji tu in tam ni kakega Marka Zuckerberga, a se ta zaradi visokih davkov navadno kmalu preseli v kako od davčnih oaz.

Nesposobni vodilni in propadanje podjetij

Čeprav veliko slovenskih podjetij daje velik pomen tako formalni kot strokovni izobrazbi in praktičnemu zanju zaposlenih, se še posebno pri družinskih podjetjih z nekaj deset zaposlenimi že pri kadrovanju nemalokrat dogajajo neverjetne zgodbe. Na primer: magister ekonomije in inženir ortopedske tehnike sta zaposlena kot vodja organizacijske enote in vodja razvojnih projektov, v vlogi direktorja prodaje je lastnikov sin, sicer gimnazijski maturant, vlogo glavnega tehnologa pa ima lastnikov drugi sin, sicer »padli« študent strojništva. Po drugi strani inženir računalništva in informatike, ki dela magisterij, dela prek avtorske pogodbe kot programer in brez možnosti redne zaposlitve ali vpliva na izboljšanje kakovosti dela. Ob julijskih napovedih OECD o 2,3-odstotnem upadu BDP v letošnjem letu in ob dodatnem 1,4-odstotnem zmanjšanju BDP prihodnje leto mu celo grozi izguba dela.

Nesposoben vodja organizacijske enote za razvoj nove programske opreme ne ve, kaj delajo njegovi vodja razvojnih projektov, programerji, tehnologi in analitiki, niti ne zna oceniti kakovosti programske kode in analitičnih izdelkov (na primer tehnični načrti) ter časa za realizacijo. Zatakne se že pri oceni časa oziroma ur dela za razvoj aplikacije, saj mora vsak sodelavec, ki sodeluje pri projektu, podati oceno za realizacijo svoje naloge, vodja organizacijske enote in vodja projekta pa ne znata preveriti, ali ni morda ocena pretirana ali preveč optimistična. Ker je optimizem zaradi prilizovanja nadrejenim navadno prevladujoč, se pogosto zgodi, da razvoj aplikacije ni končan v projektnem roku.

Še težje je pri oceni kakovosti aplikacij med razvojem. Pravilnost funkcionalnega delovanja aplikacije lahko preverimo strojno ali ročno, če prej izdelamo ustrezen testni scenarij. Pri tem ima vodja projekta veliko lažje delo pri aplikacijah, ki pri odločitveni logiki uporabljajo tabelarični pristop. Dovolj je namreč, da preverimo pravilnost delovanja procesne logike za procesiranje tabel, nato pa samo še preverjamo vsebino tabel, kar je bistveno lažje od pregledovanja programskih struktur »špageti kode« iz hierarhično urejenih pogojnih programskih stavkov ali preverjanja vseh mogočih kombinacij različnih tipov vnosnih podatkov. Slednje je namreč skoraj vedno mogoče narediti samo v omejenem obsegu, se pa zato pogosto dogaja, da aplikacija v produkciji odpove pri robnih pogojih. Na primer ko v njej še ni nobenega dokumenta. Pri testiranju med razvojem aplikacije namreč s primeri postopoma polnimo testno podatkovno zbirko, pri prvi namestitvi v produkcijo pa je ta navadno povsem prazna.

Zmogljivost programske in strojne opreme sicer lahko preverijo z obremenilnim testom, a vodja organizacijske enote, ki razume samo ekonomijo in osnove projektnega vodenja, ne pozna ozadja in rezultatov ne zna pravilno interpretirati. Zato je zadovoljen z vsakršno rešitvijo, samo da mu nekdo reče, da deluje. Hkrati ne ve, koliko bo stalo vzdrževanje zaradi razbohotene »špageti kode«. Sodelavci pri projektu so kot obrtni mojstri, ki morajo zagotoviti le zahtevane funkcionalnosti, katerih dejanske kakovosti ne zna preveriti nihče. Pogosto se izkaže tudi, da programerji precenijo svoje sposobnosti in ne dosežejo roka izvedbe, ki so si ga sami zadali.

Marsikdo bo ob tem pomislil, da gre za prvoaprilsko šalo. Žal se je v preteklosti marsikatero od takih podjetij pojavilo tudi v vlogi pomembnega dobavitelja programske opreme za javno upravo. Slaba usposobljenost vodilnega kadra podjetju onemogoča, da bi nove posle pridobilo prek (javnih) razpisov v tujini ali neposredno, na primer s trženjem svojih izdelkov (programov) prek spletnih strani. Odvisna so predvsem od naročil iz slovenske javne uprave in poznanstev vodilnih. Mnoga taka podjetja zato danes, v času vladnega varčevanja, propadajo in so prisiljena odpuščati tudi redno zaposlene. Nasprotno pa je z manjšino preostalih, ki so se prav zaradi kakovostnih storitev in izdelkov sposobna preusmeriti na druge računalniške trge in celo zaposlujejo nove sodelavce. Uspešnejša so tudi na tistih malo slovenskih javnih razpisih, kolikor jih je še ostalo, saj lahko za isti finančni vložek ponudijo bistveno več in na nekaterih področjih že izpodrivajo »zabetonirane« dolgoletne ponudnike.

Odvisnost slovenskih računalniških podjetij od poslov s slovensko državo lahko preverimo na spletni strani http://supervizor.kpk-rs.si/, če vnesemo ime podjetja in preverimo odstotek prihodkov iz javnih naročil.

Je dober programer tudi poslovno uspešen programer?

Programerji pogosto nimajo ustrezne izobrazbe in izkušenj iz teoretičnih osnov programiranja in mednarodno priznanih standardov ISO za področje razvoja programske opreme. Navadno dobro poznajo le eno ali dve programski orodji, v katerih pretežno razvijajo novo programsko opremo. Preveč se zanašajo na razpoložljive programske knjižnice v okviru razvojnega okolja in so hkrati povsem nemočni, ko morajo z osnovnimi ukazi sami napisati kompleksno funkcijo, ki je ni v nobeni od razpoložljivih (tudi plačljivih) programskih knjižnic.

Eden od zelo priljubljenih problemov na tem področju je krmiljenje delovnega toka dokumentov, ki jih želimo upravljati z aplikacijo. Je sicer dokaj enostavno rešljiv z uporabo teorije končnih avtomatov in tabel, v katerih opišemo prehode stanj dokumentov in pogoje za njihovo izvajanje, vendar večina samoukih programerjev raje »razmišlja v pogojnih stavkih«, ki ne zahtevajo fakultetnega teoretičnega predznanja. Namesto tega lahko dober vodja projekta usmerja delo tako, da programer pripravi programsko podporo za procesiranje tabel, analitik pa definira njihovo vsebino; kar je tudi bistveno hitreje, kot če analitik razlaga programerju, kako napisati pogoje, ali pripravi nepregleden besedni opis. Dovolj bi bila že vsebina tabele s prehodi stanj in njen kratki splošni opis.

Kljub temu še danes mnoge rešitve »priznanih« izdelovalcev programske opreme v slovenski javni upravi uporabljajo hierarhijo pogojnih programskih stavkov (stavki »IF THEN ELSE«). Tako kodo je v primerjavi s tabelarično obliko izjemno težko vzdrževati, hkrati pa vsak popravek pomeni nameščanje nove različice aplikacije. Za nameščanje v produkcijsko okolje javne uprave je zaradi zagotavljanja zanesljivosti delovanja in varnosti podatkov pogosto potrebnih štiri ali več ur. Popravek vrednosti v tabeli prehodov stanj je neprimerljivo hitrejši in lahko vzame tudi samo nekaj minut, saj ne zahteva nameščanja nove različice aplikacije.

Mnogi programerji zmotno mislijo, da lahko z uporabo hierarhije pogojnih stavkov dosežejo hitrejše delovanje aplikacije. Vendar ob tem pozabljajo, da lahko sodobni računalniki z nekaj GB glavnega pomnilnika celotno tabelo prehodov stanj obdelajo tako hitro, da to v ničemer ne vpliva na siceršnje delovanje aplikacije in uporabniško izkušnjo. Bistveno je le, da aplikacija ob zagonu oziroma spremembi vrednosti v tabeli prehodov stanj v podatkovni zbirki v pomnilniku računalnika ustvari njeno kopijo. To pomeni, da procesiranje končnega avtomata ne zahteva dostopa do podatkovne zbirke oziroma diskovja, ki je glavni upočasnjevalec delovanja poslovnih aplikacij.

Opisali bi lahko še veliko primerov, kjer lahko dober vodja projekta, ki hkrati razume tudi delo analitika, tehnologa in programerja, bistveno prispeva h kakovostnim in optimalnim rešitvam, vendar naštejmo samo tri: izvedba rekurzije (kjer je potrebno), uporaba hierarhičnih tabel za preverjanje pravilnosti zgradbe vhodnih in izhodnih dokumentov (pogosto potrebno, če interpreter za XML ne daje ustreznih opisov napak v strukturi glede na shemo XSD) in sortiranje s hitrimi metodami, ki dobro delujejo na veliki količini podatkov.

Zelo pomembno za vzdrževanje in nadaljnji razvoj aplikacij je tudi dosledno pisanje komentarjev v programski kodi, s katerimi besedno opišemo pomen posameznih delov programske kode.

Programerji se večinoma temu delu izogibajo na vse načine, tudi z grožnjami, da bodo odšli drugam v službo. V nasprotju s področnimi standardi ISO dobra »špageti koda« ne sme imeti komentarjev, sicer je lahko nesposoben programer brez teoretičnega predznanja v kriznih časih kaj hitro ob službo. Napisana mora biti tako, da jo lahko vzdržuje le tisti programer, ki jo je napisal. Ko se slednji upokoji, svoje znanje v obliki ustnega izročila prenese svojemu nasledniku in »obrtna tradicija« živi naprej …

Kako naprej?

Le malokdo v obdobju gospodarskega razcveta razmišlja o zgornjih vprašanjih, saj takrat ni pomembno, koliko denarja država porabi, ampak predvsem, kako ustvariti posel svojemu sorodniku, prijatelju ali znancu. Danes so pomembna delovna mesta, danes je pomembna tehnološka odličnost (kakovostna rešitev, ki jo je mogoče preprosto in poceni nadgrajevati in je ekonomsko upravičena ne le na kratki rok, temveč tudi dolgoročno), danes brez dobrega vodstva podjetja, kakovostnih vodij projektov, tehnologov, analitikov in programerjev preprosto ne gre. Vse to pa zahteva novo podjetniško strategijo.

Veliki naročniki programske opreme bodo morali s pozornejšo izbiro ponudnikov in boljšo specifikacijo zahtev glede kakovosti programske kode doseči, da na javnih razpisih ne bodo več zmagovala slabo usposobljena družinska podjetja, ampak tista, ki lahko ponudijo vrhunske strokovnjake in kakovostne rešitve. Kakovost večjih in dražjih aplikacij za javno upravo bi morali zagotoviti tudi skrbni pregledi neodvisnih računalniških strokovnjakov, ki bi naročnika opozorili na pomanjkljivosti (na primer če v kodi ni komentarjev, če je arhitektura slabo opisana) in skrite napake (na primer aplikacija bo izredno slabo delovala čez eno leto, ko bo narasla količina podatkov v podatkovni zbirki) v aplikacijah in zahtevali njihovo odpravo v garancijskem roku, ne pa da so naročniki po njegovem izteku prisiljeni plačevati za popravke skritih napak, ki se pokažejo šele po daljši uporabi.

Lahko le upamo, da bo gospodarska kriza pometla s slabimi poslovnimi praksami in bo slovenska računalniška industrija končno začela v velikem delu tržiti svoje rešitve tudi v razvitem zahodnem svetu.

Moj mikro, september – oktober 2012 | dr. Simon Vavpotič