DT blogi

Aeg-ajalt kirjutan ma siia ka paranähtustest tarkvaraarenduses. Mõtlesin, et tänagi võiks natukese üldisemal teemal jutustada ja võtta vaatluse alla, mis juhtub, kui andmed valatakse rakendusele selga nagu oleks keegi suure õlitünni ümber ajanud. Pealtnäha pole see probleem ehk hirmsaim, mis juhtuda võib, kuid lahkamisel see arvamus ehk muutub.

Nime “The mind is terrible thing to taste” pani ühele oma algusaastate plaadile industriaalset metalli viljelev loominguline kollektiiv Ministry. Tundub, et algne pisut väänatud fraas peab tihti paika, kui mõnelt süsteemilt kergitada kaas ja sisse piiluda. Hiljuti puutusin kokku ühe päris mahuka elajaga, millel hoolimata kõrgest east puudus nii arhitektuur, tehniline disain kui ka ühtne andmete käsitlus. Otsustasin paar väikest mõtet siiagi poetada, äkki on kellelgi sellest kasu.

ADO.NET valedes kätes

Tihti hakkab õnnetus pihta ohtratest artiklitest ja juhenditest, mis tutvustavad ADO.NET-i kui taevamannat ja õiget teed, mida minna. Rakenduse kasvades saab sellest väikeste sammude kaupa aga õudusunenägu, mis levib läbi rakenduse nagu ravimatu vähkkasvaja. Kujutage ette rakendust, mille äriklassid on täis koodi, mis küsib ADO.NET andmeid, kombineerib tabelitest andmeid ja moodustab uusi ADO.NET-i objekte, et need anda tagasi kasutusliidesele või teistele klassidele, mis taolise keemiaga edasi tegelevad.

ADO.NET-il on oma kindel koht rakendustes, kuid kindlasti ei pea ADO.NET-i objektid rändama läbi kõikide rakenduse kihtide. Keegi suurtest objekt-orienteeritud maailma isandatest nimetas taolist lähenemist tahtlikuks kuriteoks oma leivaisa vastu. Ja peale taolise salati nägemist saan aru, et ta oli oma ütlusis isegi leebe.

ADO.NET objekte on hea kasutada pisemates rakendustes, kuid kui meil on juba tegemist millegi sellisega, kus me jagame rakenduse erinevatesse kihtidesse, siis ADO.NET koht on andmekiht ja kaugemale see ulatuda sealt ilma hea põhjuseta ei tohiks. Või vähemasti ei tohiks see näha olla muudesse kihtidesse otse, sest alati leidub mõni vähe kogenud arendaja või muidu tuulepea, kes pikemalt mõtlemata sellest haarab.

Aja jooksul tekkivad probleemid

Probleeme, mis aja jooksul tasapisi väikeste sammudena tekib, ei ole just vähe. Ja oma olemuselt on need väga halvad, sest viivad vääramatult rakenduse kas surma sel teel, et selle hoolduskulud kasvavad taevasse või muutuvad uued arendused hoolimata mahust järjest utoopilisemaks oma hindadelt. Lisaks sellele kasvab ajakulu samas rütmis. Peamised probleemid, mis tekivad ja mille parandamine on jube kulukas, on järgmised.

• Palju korduvat koodi – kuna andmed liiguvad mööda rakendust ringi nii objektide kui ka ADO.NET tabelitena, siis tekib mitmeid kohti erinevates klassides, kus mõni uus objekt nagu mullamutt oma nina maa seest välja pistab. Kui objekt saab juurde uue omaduse, siis tuleb teha vastav andmetega seotud muudatus kõikjale, kus antud objekt ADO.NET andmetest kokku pannakse.
• Korduvad andmete teisendused – mitu haru lähtekoodis, kus ADO.NET kasvaja läbi on harud ajanud, vajavad andmete teisendamist ning teisendused rakendatakse kohtades, kus neid kas kohe või peatselt vaja läheb – iga arendaja teeb seda paraku enda kõhutunde järgi, sest reegleid pole kokku lepitud. Tulemus sama, mis eelmisel juhul.
• Dubleeritud päringud – varem või hiljem leiab keegi andmebaasi liiklust optimeerides, et igati hea plaan on pärida ühe päringuga ära ka seonduvate objektide andmed. Miks mitte teha nii, kui näiteks O/R-mapperites on taoline strateegia kasutuses? Nüüd jõuame segadusega uuele tasemele – üks muudatus ühes tabelis võib põhjustada näiteks paarkümmend sarnast muudatust lähtekoodis erinevates kohtades. Inimtööd kulub sellise muudatuse tegemiseks mõnusalt. Kui on tegemist uue arendajaga projektis, siis pole imestada kui antud muudatuse tegemine koodibaasi võtab tal aega nädal või enam.
• Hüppeliselt kasvav keerukus – iga uuendusega muutub rakendus järjest keerukamaks, sest “ummistunud” kohad, kus on tegevusi juba liiga palju, jäävad puutumata ning nakkuse saavad omale külge järjest uued kohad, mis seni on olnud õhukesed ja lihtsasti käsitletavad. Selle tulemusena muutub kood väikeste sammudena veelgi raskemini hallatavaks ja kontrollitavaks.

Kindlasti võib siia nimekirja lisada muidki probleeme. Näiteks tähendab taolises rakenduse korral lihtne muudatus andmebaasis seda, et üle tuleb testida kogu süsteem, mitte ainult see süsteemiosa, mida antud muudatus puudutas – mine tea, kus nurga taga veel vastavat tüüpi objekte luuakse.

Probleemid äripooles

Äriline pool hakkab antud problemaatika tekkimisel ja kasvamisel samuti uppuma probleemidesse, mida on järjest raskem ja raskem lahendada. Probleemid on lühidalt sellised.

• Ebatäpsed ajahinnangud – ajaliste hinnangute andmine uutele funktsionaalsustele muutub järjest ebatäpsemaks, sest arendajad suudavad järjest vähem hinnata kohtade arvus süsteemis, mida antud uuendused mõjutavad.
• Palju tasuta tööd – eelnevalt mainitud ebatäpsused toovad endaga kaasa palju sellist tööd, mis on ootamatu ning kasvab välja äkitselt nagu tapjalaine vaiksest veest. Kliendi käest ei saa raha juurde küsida, sest tema on lähtunud uute funktsionaalsuste tellimisel oma eelarvest ning jutt näiteks viis korda kallimast hinnast võib lõppeda kliendisuhte katkemisega. Paraku on enamasti nii, et sellisel juhul teeb teostaja antud tööd ära oma taskust, oma arendajate ületundide arvega, et graafikus püsida.
• Uute tööde alustamine viibib – kui ajamahukaid “uudiseid” on kuhjunud piisavalt, siis valitseb tööde ajakavas juba parandamatu kaos. Uued tööd, millega arendajad peaksid kohe-kohe alustama, viibivad ning keegi ei oska öelda, millal nad probleemid lahendatud saavad. Samal ajal toob iga arvel olev päev välja veel uusi probleeme, mille lahendamiseks pole ei aega ega raha planeeritud.

Mida kõrgemalt tasemelt vaadata, seda suuremad need probleemid on.

Mis saab sellisest süsteemis edasi?

Enamasti loetakse taolisesse punkti jõudnud süsteem ebaõnnestunud, läbikukkunuks ning arendus peatatakse. Tellija otsib omale uued teostajad ning leiab rahalised vahendid süsteemi uueks versiooniks, mis ehitatakse üles alates nullist. Kuid nii ei lähe see igakord.

Kui süsteemi on ehitatud piisavalt kaua ja see on juba aastaid olnud kasutuses, siis võidakse otsustada ka perestroika kasuks, mille käigus tehakse kaosest kord. See ei ole ei lihtne ega odav protsess, kuid kui lasta kaosel edasi kasvada tõuseb selle likvideerimise ajakulu päevast päeva suurte hüpetena.

Milline on parim variant taolise süsteemiga edasi liikumiseks sõltub juba konkreetsest olukorrast ja probleemistikust. Ühest valemit ei ole ning enamasti mängib olulist rolli ka see, milliseks on antud ajaks kujunenud tellija ja teostaja suhted.

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