DT blogi

Väike jutustus sellest, kuidas tarkvara projektid hapuks lähevad ning mida selleks kindlasti teha tuleks, et nii juhtuks. Neid samme järgides on projektide õnnestumine ning kogu ettevõtte kollektiivi heameel sama hästi kui 100% eos välistatud. Head lugemist!

Mõnikord on tulnud tööväliselt ja hoopis teises seltskonnas jututeemaks see, kuidas tarkvara projektid ebaõnnestuvad ja mis on need vead, mida inimesed teevad, et kõik nii hullusti metsa läheb. Peamised vead, mida tarkvara arendusprojektides tehakse, on koos oma tagajärgedega järgmised.

NIH sündroom

Not Invented Here sündroom iseloomustas kunagi Apple’it, kes tahtis kõik oma süsteemide osad 100% ise teha. Majavälistesse asjadesse suhtuti ilma lähema tutvumiseta teatava põlgusega.

Arenduses kaasneb selle sündroomiga projektide tohutu ajalistest raamidest väljaminek, sest ka keerukamad komponendid, mille võiks osta või mille avatud lähtekoodiga versioone võiks kasutada, püütakse kirjutada majasiseselt. Isetegemise otsuste valguses võetakse ka keerukate komponentide arendamist kui midagi lihtsat ja jõukohast, sest ometi “meie oleme ju professionaalid ja teame kõike väga hästi.”

Tüüpiline näide on siinkohal näiteks O/R mapperite kirjutamine. Kui palju on mappereid või nende analooge arendusprojektides loodud, pole selge, kuid see arv on tõenäoliselt tohutu. Tihti lastakse siinkohal endale väga valusalt jalga - mapperi kirjutamine pole nalja asi, sest mapper kõlgub oma olemuselt kuskil kahe kihi vahel. Ta pakub meile välja küll hea andmekihi, kuid ühtlasi on ta ka meile objektide loomise mootoriks. Mapper peab lahendama ära terve rivi ülesandeid ning seni parimad mapperid pole sündinud mitte ühe projekti raames, vaid need on muutunud tugevaks tänu aastate pikkusele tööle ja suurele kasutajate arvule. Ei tasuks unustada ka seda, et elujõuliste mapperite taga on keskmisest ikka päris mitme pea jagu kõrgema tasemega programmeerijad.

Neid näiteid võiks tuua terve rivi, kus inimesed on kulutanud oma kallist aega ja tellija kallist raha täiesti mõttetult õigustamatu isetegevuse peale, selle asemele et osta keerukad asjad sisse ning panna põhirõhk tellija soovide täitmisele.

Miljon raamistiku

Järgmine laialt levinud teema on see, et püütakse luua süsteemi jaoks uut raamistikku, kuigi on olemas arendusvahendite enda poolt toetatud raamistikud, samuti leidub lähemal uurimisel mitmeid teisigi häid raamistikke, mille kasutamist tasuks kaaluda.

Peamiselt tekib raamistike häda PHP peal, sest seal valitses selles osas pikalt päris nukker seis - polnud ühtegi tugevad raamistikku ja oma raamistikku polnud pakkuda ka PHP tootjal - Zend’il. Niisiis juhtus PHP maailmas nagu Piiblis, kui inimesed torni taevani ehitasid. Ainult et keelte asemel olid raamistikud - iga mees sai äkki enda raamistiku, mis oli vaieldamatult teiste omadest parem.

Tulemus - surnult sündinud süsteemid. Algajate ning väheste teadmiste ja kogemustega programeerijate poolt kirjutatud raamistikud määravad iga veebirakenduse hukule, sest enamasti on need raamistikud läbimõtlemata ning vähegi keerukamate tellija soovide täitmine nende peal küllaltki võimatu. Tellija soovide kasvades kasvab raamistik arendajatel üle pea ning peagi leidub seal külluses kõiksuguseid häkke, mis muudavad kogu raamistiku kasutamise veelgi segasemaks.

Tellijale tähendab see lõpuks seda, et iga soovitud muudatus ja täiendus on teostuse osas ajaliselt ja seega ka rahaliselt järjest kulukam. Lõpuks pole süsteemiga enam suurt midagi peale hakata ning tellija hakkab valima uut teostajat. Sellel põhjusel on ka meie poole päris palju pöördutud, muide.

Raamistike kirjutamine pole lihtne ülesanne ning see eeldab tugevaid kogemusi süsteemide kirjutamisel. Samuti peavad raamistikku loovad programmeerijad olema äärmiselt hästi kursis süsteemide arhitektuuri poolega. Igal juhul noorte mängumeeste maa raamistike kirjutamine kohe kindlasti pole.

Rõhk valedel asjadel

Alati saab pakkuda igasuguseid lahedaid ja kaasaegseid asju. Tihti mängitakse siin ennast kinni sellega, et lahedad ja elutähtsate funktsionaalsustena võimaluste realiseerimine käib arendajatel üle jõu. Nii võivad inimesed lõpuks pusida mingite kasutajatele nähtamatute asjade kallal, ilma et kasutajate elu sellest märgatavalt paremaks muutuks.

Siia gruppi lähevad tihti kasutusliidese igasugused ilusad lisavidinad, mida tellijal tegelikult vaja pole. Samuti kõiksugu “ülilahedad võimalused, mida keegi teine turul niisama ei paku”. Peamiselt on siin taga see, et mingitel biti-baidi poistel on igav ja nad tahavad midagi lahedat teha. Tellijale kvaliteedi pakkumine on nende jaoks tihti midagi väga igavat ning et keegi neile pole vastavaid väljakutseid tutvustanud, ei oska nad uneski näha, et tellija võib olla see suur juht ja õpetaja, kelle soovide mõistmine ja nende soovide võimalikult optimaalne lahendamine on just see väljakutse, mis nii firma enda kui ka selle personali taset uue teabe näol turul tõstavad.

Ma olen näinud projekte, kus tegeldakse põhilise funktsionaalsuse asemel sellega, et arutatakse lõpututel koosolekutel seda, kuidas mingi link kuskil vähemärgatavas ribas välja näeb ning kuidas peaks toimima üks või teine asi, mida programmi sihtgrupp kunagi kasutama ei hakka. Valede asjadega tegelemine viib pea alati ühe tulemuseni - projekt ebaõnnestub.

Granaadiga kärbsejahil

Sellise nimetuse annan ma ühele veidrale tegevusele, mille sisuks on see, et muidu arukas tunduv inimene püüab lihtsaid probleeme lahendada nagu suuri probleeme. Tegemist on ühe halvima variandiga ning peamiselt juhtub see tarkvara arhitektuuri alal. Tihti saab selle vea tagajärjel suurepärasest ärisuhtest üks suur sõda, mis ei too tulu kummalegi poolele - kaotavad kõik.

Tüüpiliselt näeb kärbsejaht välja selline. Enne kui süsteemi ehitamiseks läheb, otsustatakse ära lahenduse arhitektuur. Selles pole midagi imelikku, sest koodi kirjutamise käigus seda enam muutma ei hakata enamasti. See on kulukas ja võib tähendada terve senitehtu loomist alates nullist. Nüüd aga leiab keegi, et selle süsteemi peaks igaks juhuks kirjutama just selliselt ja selliselt ning küllaltki lihtne rakendus, mida võiks lugeda prooviversiooniks, saab omale äkki arhitektuuri, mis vastab keerukamatele ettevõtete infosüsteemidele.

Ma olen korduvalt näinud seda, kuidas hakkab lihtsa rakenduse taha tekkima mingi selline arhitektuur, mille vajalikkust teostaja ei suuda isegi põhjendada. Miks ei suuda? Sest mingis targas raamatus oli juttu, et nii on õige. Halb lugu on see, et tark raamat ei maini tihti konteksti, kus antud lähenemist kasutada. Nii jõuab lihtsa rakenduse taha arhitektuur, mille peale kulub algul planeeritust aega tunduvalt enam, sest tark raamat ei soovita lugejal endas ega raamatus kahelda ning lugeja on lõpuks tohutus hämmingus, kui näeb, kui palju aega tema suurepärase arhitektuuri realiseerimine tegelikkuses nõuab.

Tüüpilised sümptomid, mida jälgida, on see, kui projekti hakkavad tekkima igasugused komponendid, mille järgi seal vajadust pole. Näiteks ei ole lihtsa rakenduse juures vaja kasutada vahendeid, mis lasevad rakendusele nähtamatult vahetada välja äriloogikat pakkuvaid komponente. Samuti pole vaja luua ülimalt korrektseid objektmudeleid kui ülesandeks on teha valmis lihtne töötav programmijupp, mis on ettevalmistuseks sellele, et ükspäev tehakse suurem ja põhjalikum süsteem.

Kokkuvõtteks

On veel vigu, mida tihti tehakse, kuni selleni, et tarkvara projekte viivad läbi inimesed, kes pole programmeerimisega professionaalsel tasemel kordagi kokku puutunud. Neist juhtumitest ehk mõni teine kord. Hmm.. samuti annaks ka siintoodud vigade kohta kirjutada mitmeid kandeid koos värvikate näidetega.

Igal juhul on siintoodu minu meelest peamine valik väga valusaid vigu, mida arenduses tehakse. Need vead lõppevad pea alati samamoodi - projekt ebaõnnestub 100%

Kirjutas Gunnar, 30.01.2008 kell 10:30, teemal Tarkvaraarendus. Jälgi selle postituse kommentaare läbi RSS-uudistevoo (feed). Lisa kommentaar või tagasisideviide (trackback) oma veebilehelt või blogist.