DT blogi

Andmevähi ravimine pole lihtsamate killast tegemine. Mida kaugemale vähk on arenenud seda vaevalisem on ka ravi ja paljudel juhtudel on ravist oluliselt soodsam alustada alates nullist. Et ma niisama vingujate vendade ja nutunaiste kampa ei kuulu, siis pakun alati probleemidele välja ka lahendused. Selles kandes tutvustan ülevaatlikul tasemel plaani andmevähi ravimiseks. Kellel kogemusi, siis kõik tagasiside – nagu ikka – on teretulnud.

Tihti mõtlevad arendajad nii, et kui miski on katki, siis küll me selle kuidagi siva korda saame. Enamasti see aga nii ei lähe, sest meie käsitleme juhtumit, kus probleemid on tõusnud või tõusmas juba taevani. Rakenduse silumine, testimine ja edasiarendamine on muutunud elusaks põrguks, millest väljapääsu ei paista olevat. Kas tunneli lõpus paistab valgus või on see lähenev rong, mis projekti lõplikult tapab?

Plaan andmevähi ravimiseks

Eelmises andmevähi kandes kirjeldasin ära probleemid lähtekoodiga. Selles kandes püüan anda tegevuskava asjade samm-sammult parandamiseks. Kes loodab leida siit hõbekuuli, siis teadku, et ainus hõbekuul on projekti alguses korralik eeltöö ja oma meeskonna järjepidev harimine. Andmevähi tootnud tiimi jaoks on see hetkel tagantjärgi tarkus.

Sammud andmevähi raviks on järgmised:

1. Koonda päringud ja objektide loomine algul manager-klassidesse. See ei ole küll hea praktika lõplikuks lahenduseks, kuid mõtle sellele nagu põrandate pesemisele – põrandalt kõrgemale tõstetud asjad jäävad sinna ainult ajutiselt. Vähemasti hakkab kord tasapisi tekkima.
2. Vii päringud ja objektide loomine eraldi klassidesse. Sel teel muutuvad ajutised manager-id oluliselt õhemaks ja lihtsamini käsitletavaks. Jälgi hoolega, et igat tüüpi objektide luuakse ainult ühes kohas, mitte mitmes. Muidu paranemist pole, vähk võtab ainult teise kuju.
3. Muuda oma lähtekoodi selliselt, et ADO.NET objekte rakenduse äriloogika ja kasutusliidese kihis ei kasutata. See tähendab seda, et mainitud kihid saavad oma objektid kätte manager-ide käest.

Ma soovitan siinkohal appi võtta ka andmebaasidega tegelevad professionaalid, sest nende käest saab kuldaväärt teavet tavaliselt ja ma ei mõista, miks hoitakse neid enamasti arendusprotsessist nii kaugel. Muide, ka see on üks andmevähi põhjuseid, et õigete meeste käest jäetakse küsimata ja püütakse ise olla sama targad, kuigi teadmised puuduvad.

Nüüd on suurem tuli kustutatud ning esmane kord majja loodud. Sama mustrit hoides on võimalik vähemalt osal tiimist jätkata uute arendustega, kuid midagi suuremahulist ei soovita ma enne täieliku korra saabumist käsile võtta. Ütleme nii, et olukord on juba parem, kuid masinaid me haige küljest veel eemaldada ei saa.

Edasise arhitektuuri valimine

Ma ütlen just nimelt edasise, sest sellist asja nagu õige arhitektuur või ideaalne arhitektuur pole olemas. Inimesed, kes sellist asja jutlustavad, meenutavad mulle alati neid pealappidega fundamentaliste, kes ühe ja ainsa idee ja jumala nimel on nõus ükskõik millisteks tegudeks. Jääme meie aga maailmaga sõbraks ja võtame teadmiseks, et arhitektuur pole kas õige või vale, vaid rohkem või vähem sobiv. Kuid igal juhul peab see arvestama sellega, kus oleme täna ja kuhu jõutakse näiteks ülehomme. Üle pole mõtet pingutada.

Nüüd tuleb hoolega hinnata rakenduse mahtu ja selle edasisi arenguid. Soovitan kliendiga selles osas nõu pidada, et saada selgem pilt sellest, kuhu näiteks lähema paari aasta jooksul püütakse jõuda. Sellest lähtuvalt saab valida ka strateegia andmetega tegelemiseks. Martin Fowler pakub oma kultusteoses Patterns of Enterprise Application Architecture välja kolm võimalikku lähenemist:

• Transaction Script – see on enam-vähem see, mis meil praegu olemas on, kuid korrastamist on vaja enam. See lähenemine sobib hästi rakendustele, mis on pisikesed ja lihtsad.
• Table Module – andmebaasi tabelile seatakse vastavusse klass, mis teostab kõik sellega seonduvad operatsioonid. Midagi sellist on meilgi osaliselt olemas. See lähenemine sobib pisut suurematele rakendustele, mis ei tegele millegi keerukaga. Peamiselt andmete edasi-tagasi liigutamine lihtsal kujul.
• Domain Model – täismahus objekt-orienteeritud objektmudel, mis kannab endas nii andmeid kui nendega seotud operatsioone.

Ma eelistan enamasti just viimast neist, kuid lihtsaid ja primitiivsemat laadi rakendusi ma sellise monstrumiga koormama ei hakka. Sellel puudub igasugune mõte ja jutt sellest, kuidas kümmet andmebaasi käsku tundev rakendus vajab täismahus teste, on suhteliselt absurd.

Koodi migreerimine uuele arhitektuurile

Peale arhitektuuri valikut tuleb otsustada ära, kuidas rakendus koodi üleviimine hakkab toimuma. Hea on mõelda, et teeme korraga kõik ühe hingetõmbega ära, kuid see toimib ainult väikeste rakenduste korral. Aastaid arendatud rakendused on enamasti nii mahukad, et vaja on plaani näiteks järgmise kuu kuni kolme või miks mitte ka pikema ajalise perioodi jaoks.

Kui tegemist on pikema ja mahukama tööga, siis üheks keerukaks kohaks saab uue arhitektuuri kasutamine paralleelselt vanaga. Need kaks asja tuleb omavahel liidestada ja neid tuleb paralleelselt kasutada vähemasti mõnda aega. Mõned soovitused:

• planeeri migreerimine väga hoolikalt – see teeb protsessi oluliselt lihtsamaks, sest keerukaid üllatusi tuleb ette niigi palju,
• kui on vähegi võimalik, siis planeeri migreerimine mõistliku suurusega tükkidena – näiteks vormi kaupa või klassi kaupa (sõltub olukorrast),
• kohad, kus tuleb paratamatult kasutada uut ja vana korraga, tee sellised, et liidestamisel ei puudutatakse uue arhitektuuriga seonduvat – ajutiselt loodud klassid kustutad sa niigi lõpuks maha ja parem nakata halbade haigustega kaduv kood, mitte see, mis jääb.

Selle tegemise lõpuks peab käes olema olukord, kus vahepeal loodud korra eesmärgilised klassid võib kõik maha kustutada.

Kokkuvõtteks

Kogu see tegemine tundub hoomatav ja üldse mitte suur, kui seda eemalt vaadata. Kes korra käed on külge löönud, see avastab, et tegemist on oluliselt rohkem, kui keegi seda alguses oskas ette kujutada. Hea plaan on ajalised puhvrid võtta sellise tegemise juures suure varuga ja kindlasti tuleb teha väga põhjalik eeltöö, et niigi suur ootamatuste arv viia miinimumi.

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