DT blogi

Vigadele ja probleemidele jahi pidamine vanemas koodibaasis on tihti peale päris karm tegemine, mis nõuab süvenemist, mõttevõimet ja tõsist suhtumist oma töösse. Võtan siinkohal kokku mõningad nõksud ja trikid, mille peaks iga vanema koodibaasiga tegelev programmeerija suutma omandada orienteeruvalt poole aasta jooksul.

1. Tunne oma töövahendeid

Oluline on tunda töövahendeid, mida probleemide lahendamisel kasutatakse. Nii tuleb hästi tunda oma programmeerimise vahendeid, keelt, milles programmeeritakse ja igasuguseid muid abivahendeid. Paljudel keelte jaoks on tänapäeval olemas arendusvahenditega liidestuvad silurid, mis aitavad jälgida koodi täitmist programmi jooksmise ajal jne.

Näide praktikast. Ühel inimesel oli kord tõsine hämming, et keel, mida ta kasutab, võimaldab selliseid ja selliseid ja selliseid asju, mis hoiavad tema tegemistes aega väga kõvasti kokku. Tegemist oli, muide, programmeerijaga, kellel reaalset töökogemust üle kahe aasta. Peale mõnda tundi tehniliste materjalide keskel tõusis inimese produktiivsus märgatavalt.

2. Tunne halbu praktikaid

Väga oluline on tunda halbu praktikaid, mida tööks olevates süsteemides on võimalik kasutada. Näiteks vigade maha surumine, hoiatuste ignoreerimine, teadmatus muutujate väärtuste päritolu kohta. Esimesed kaks halba praktikat on üldised - neid kasutatakse pea kõikides keeltes, kus seda vähegi teha annab. Viimane halb praktika on peamiselt PHP programmeerijate tõmbenumber.

Korras kood ei anna kompileerimisel hoiatusi, ühtegi viga ei suruta maha ning iga muutuja kohta on selge, kus kohast ja millal ta omale väärtuse saab. Näiteks seni kohtab veel tohutult palju PHP koodi, kus hoiatuste sisse lülitamisel on ekraan hoiatusi tihedalt täis. Mida on mõelnud programmeerijad, kes nii ebakvaliteetse koodi suure ilmarahva ette toovad, pole mulle siiani selge.

Näide praktikast. Kunagi ammu, kui PHP peal suuremaid asju hakkasin kirjutama, lugesin läbi terve rivi artikleid heade ja halbade praktikate kohta. Selle tulemusel muutusin võrreldes senisega PHP peal kordi produktiivsemaks, sest minu kirjutatud kood osutus töökindlaks ja hästi hallatavaks. Peale mõnda kuud lugemist ja praktiseerimist jõudsin sinnani, et minu kirjutatud kood oli 100% minu kontrolli all ja seal ei olnud ühtegi “halli laiku” ehk ma-ei-tea-miks-see-nii-tööle-jäi kohta.

3. Muuda kood jälgitavaks

Tihti tuleb vanemat koodi testida küllaltki spetsiifilises keskkonnas, kus on täidetud igasugused erinõudmised ning üldise arendusserveri kasutamine laneb seega ära. Kui süsteem on segane, siis soovitan ehitada mehanismi, mis aitab koodi täitmist jälgida. Paljudel täna kasutuses olevatel süsteemidel selline võimalus näiteks puudub.

Kõige kiirem ja efektiivsem on luua logimise jaoks näiteks mõni funktsioon, mida saab igalt poolt kätte. See funktsioon võib väljastada oma logi otse ekraanile sel juhul, kui käesolevale kasutajale on selline funktsionaalsus lubatud. See tähendab seda, et tehnikud saavad rahulikult uurida probleemseid toiminguid ilma, et nad teisi kuidagi segaksid.

Näide praktikast. Ühe küllaltki mahuka ja päris probleemse süsteemiga tegelev inimene vastas mu küsimusele koodi jälgimise kohta, et seda on ta natukene isegi teinud. Korralikku jälgimise süsteemi, mis oleks ehk ekraani jagu koodi, polnud selles süsteemis olemas. Olemasolev natukene ei omanud mingit väärtust, sest andis vaid murdosa vajalikust infost. Iga vea korral kulus seega tohutu hulk aega selleks, et jälgida koodi täitmist ning nuputada, millise süsteemi osa kätte järgmiseks kontroll läheb. Korraliku jälgimise süsteemi abil oleks tulnud vaid võtta mõni sisenemispunkt ning lisada funktsioonide ja meetodite algusesse rida koodi, mis kirjutab logisse rea.

4. Dokumenteeri ja kommenteeri

Tihti juhtub nii, et probleemne koodibaas sisaldab mitmeid halbu otsuseid ja päris palju segast koodi. Kõike seda ei jõua avastamise hetkel mitte keegi ära parandada, sest töötavad parandused tuleb enne välja mõelda, siis ära teha ja seejärel põhjalikult testida.

Mida jõuab alati teha, on see, et kirjutada mõne segase koha juurde enda ja teiste tarbeks kommentaar. Juba käputäis kommentaare segaste kohtade juures aitab teinekord aega kokku hoida tõsiselt - nii kommenteerijal endal kui ta teistel, kes sama koodiga peavad hiljem tegelema.

Näide praktikast. Jällegi üks süsteem kaugemast ajast, kus kood suur ja segane. Inimene, kes süsteemiga tegeles, ei vaevunud segaseid kohti kommenteerima. Selle tulemusel kulutas ta tohutult aega (loe: leivaisa raha) mõttetult ära, sest iga vea korral pidi ta ennast uuesti ja uuesti samast probleemsest koodist läbi närima. Kui kuuled korduvalt sama koha kohta juttu stiilis ega-ma-hästi-ei-mäleta-kuidas-seal-on, siis ole valmis halvimaks - see olukord ei lahene enne, kui tegeleja on omandanud elementaarsed programmeerimise praktikad või kui oled selle töö andnud inimesele, kes oma elukutsesse tõsiselt suhtub.

5. Õpi infot leidma

Interneti suur pluss ja ühtlasi miinus on tohutu saadaolev infohulk. Jah, siit leiab pea kõike, mida vähegi tahta oskad, kuid tihti on leidmine küllaltki aeganõudev. Mõne kuuga tekib asjalikul programmeerijal välja oma andmekanalite hulk. Brauseri järjehoidjate hulka tekib päris hea ports väärikate saitide linke ning RSS-voogude lugejast leiab mitmeid väga häid blogisid.

Teine asi, mille programmeerijad peavad edukaks töötamiseks ära õppima, on otsingumootorite kasutamine. Pealtnäha tundub see lihtne, kuid tihti see nii pole. Info efektiivne leidmine eeldab tihti pikemat mängimist probleemi või otsitavat infot iseloomustavate märksõnadega. Kui otsimist käsitleda kui kestvat protsessi, mille käigus õpib koguaeg juurde, siis asub pea kõik vajalik info meist paari hiireklõpsu kaugusel.

Näide praktikast. Ma-vist-natuke-vaatasin-ka-vastused probleemide lahendamise kontekstis näitavad, et programmeerija pole teinud ära olulist kodutööd. Oma probleemi kirjeldav programmeerija, kes on õppinud infot leidma, teab mainida infoallikaid, millest ta probleemile püüdis vastuseid leida. Kes info leidmise on omale selgeks teinud, leiab kiiresti üles mitmekülgse info. Need, kes seda teinud pole, ütlevad ka lihtsate probleemide kohta, et internetis infot selle ja tolle teema kohta pole.

6. Õpi selgeks head praktikad

Head praktikad on asjad, mida tuleb õppida koguaeg. Tihti ei ole nad vastandid halbadele praktikatele ja neid ei mõtle keegi niisama lihtsasti välja. See kõik tuleb ajaga. Headest praktikatest kirjutavad paljud raamatud, ajakirjad ja kodukad. Samuti tasub silma peal hoida enda tegemistel, sest mõni oma igapäevases töös kasutatav sissekulunud nõks võib olla sedavõrd väärtuslik, et seda võiks kasutada ka kõik teised inimesed, kes sama tehnoloogiat kasutavad.

Näide praktikast. DT raamaturiiul erineb päris palju sellest, mida ma mujal kontorites olen näinud. Siinkohal on meil Marek näinud vaeva ja andnud igasuguseid häid soovitusi raamatute kohta, mis võiks meil olemas olla. Need, kes meist hoolega loevad, arenevad kiiresti ja nende jaoks ei sisalda käesolev kanne mitte midagi uut.

7. Hoidu ülimalt-elitaarsest-koodist

Ja hoidu seepärast, et see pole elitaarne, vaid kellegi must huumor. Elitaarne kood, kellele see termin meeldib, on see kood, mis on loetav ja hallatav ja mis ei tegele musta maagiaga. Kindlasti on kohti, kus näiteks jõudluse huvides tuleb kasutada mingeid trikke. Sel juhul tuleb ka vastavad kohad kommenteerida, et keegi seda koodi ilma hea põhjuseta loetavaks ära ei parandaks.

Näide praktikast. Olin kord sunnitud kasutama koodi, kus tehti igasuguseid kavalaid asju. Kasutati reflektsiooni, puhverdati tüüpe ja eisnes ohtralt muidki nõkse, mis kõik ühte pühat eesmärki täitsid. Selle koodiga oli tegeleda küllaltki keerukas, sest vigade korral tuli tükk aega nuputada, miks üks või teine asi just nii on tehtud ja miks mitte ei ole need asjad lahendatud kuidagi teisiti. Veaolukordades tuli samuti läbi käia äärmiselt pikk logi ning need probleemid muutsid antud süsteemiga tegelemise ajaliselt äärmiselt mahukaks.

8. Sinu kolleegid võivad olla väga targad

Varem või hiljem avastab iga koodija, et probleemide korral on kasulik rääkida oma kolleegidega. Mõni inimene neist oskab probleemi lahendada kahe lausega - kas seepärast, et ta on varem sarnast probleemi pidanud lahendama või on tal rohkem kogemusi või on ta lihtsalt inimene, kelle sooviks on saada üheks parimatest omal alal.

Kindlasti pole hea plaan oma kolleegidel kõik oma tööpäevad kukil elada. Kuid kui tekib kahtlus, et lihtsa probleemi lahendamisel jääb midagi märkamata, siis tasub alati küsida nõu. Ka selle venna käest, kellel on räigelt kiire ja räigelt palju teha - äkki on tal seepärast palju tegemisi, et ta produktiivsus ja kogemuste hulk on päris kõvad.

Näide praktikast. Kunagi väga ammu kui alustasin, olin kindel, et lahendan kõik probleemid ära iseseisvalt. Peksan peaga müüri nii kaua kuni kive kukkuma hakkab. Saagu peast, mis saab, kui katki läheb, siis küll kunagi saab terveks. Peagi  aga õppisin ära selle, et “jõuga” tegutsemine ei anna olulist efekti - vaja on mõelda, vaja on mõnikord küsida nõu, vaja on istuda maha ja mõelda ning siis tegutseda. “Jõuga” tegutsemine ainult väsitab ja tapab vaimselt. Kuid õigesti tegutsedes on võimalik ka keerukate probleemide lahendamist nautida.

Kokkuvõtteks

Need olid punktid, mis mul käisid esimesena peast läbi. Lühidalt võiks kokku võtta need punktid selliselt: programmeerimine on pidev õppimine, mõttetöö ja kommunikatsioon. Koodiridade osa on enamasti kõige lihtsam osa kogust protsessist enesest. Tugev programmeerija arendab ennast kogu arendusprotsessi osas, nõrgemad isendid kaklevad aga elu lõpuni just lihtsamate ülesannetega, sest protsessi ei suuda nad ennast nii sujuvalt mahutada. Ühtlasi tähendab see seda, et probleemset koodi haldab oma elukutse vastu huvi tundev ja ennast pidevalt arendav programmeerija väga efektiivselt.

Oluline on ennast pidevalt täiendada, mõelda probleemidele lahendusi, muuta probleemsete kohtade mõju enda tegevusele minimaalseks ja otse loomulikult - oluline on suhelda inimestega. Programmeerijad, kes saavad aru arendusprotsessist ning harivad ennast selles kontekstis, muutuvad järjest efektiivsemaks ning nemad on firmale oluline vara. Kes aga plaanivad elu lõpuni toore jõuga sama seina igakord peaga purustada, peavad arvestama, et oma karjääri jooksul vahetavad nad töökohti umbes sama tihedasti kui sokke. Lugu on lihtne - professionaal ei tekita, vaid lahendab probleeme.

Käesolev nimekiri võttis kokku asjad, mis aitavad tegeleda nii probleemse kui ka probleemitu koodiga. Need kaheksa asja peaksid kohale jõudma esimese tööaasta jooksul - juhul kui inimesel on oma elukutse vastu huvi ning ta julgeb vastu võtta ka tõsiseid väljakutseid.

Lõpetuseks

Kindlasti leidub veel mitmeid punkte, mida siinkohal tasub ära märkida. Kes arvab, et võiks siia nimekirja veel midagi lisada või võiks siit midagi vähemaks võtta, siis palun - olen avatud kõikidele kommentaaridele nagu alati.

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