::: Mõningad soovitused programmeerijale

     Autor: Ingmar Tammeväli
  • Soovitus: 1

    Ära ennem hakka koodi kirjutama, kui lähteülesanne pole lõplikult selge. Selle aluseks on enamasti hea infosüsteem RUP stiilis, kui on ikkagi mingeid arusaamatuid nüansse, siis pöördu analüütiku/projektijuhi poole (isik, kes koostas ülesande).

  • Soovitus: 2

    Tööülesanded peaksid olema kõik esitatud Sulle kirjalikult, et vältida tulevikus arusaamatusi.

  • Soovitus: 3

    Programmides kasutage maksimaalselt objekt-orienteeritud loogikat; meetodite/muutujate pärimine, ülekirjeldamine;private,public,protected sektsioone.

  • Soovitus: 4

    Hoidke firmas ühist abimoodulit, kuhu kasutajad saavad lisada uusi funktioone/protseduure Näiteks Teil on vaja e-post kontrolli,isikukoodi kontrollida. Siis väheneb dubleeriva koodi tekkimise võimalus (dubleeritav kood on juba nõrkuse märk meeskonnas). Delphis on olemas ka visuaalsed komponendid mida saate ise koostada, sellised komponendid võiksid olla ka jagatud firma siseselt. Keegi meeskonnas on teinud uudse kuupäeva sisestuse akna või TdbGridi, kus lahtrites kuvatav info on värviline ja eventidega juhitav, neid näiteid on veel palju. Kõik see ressurside jagamine kiirendab tööde valmimist ja hoiab koodi ühtsena !

  • Soovitus: 5

    Protseduuride oodatavad sisendid/väljundid/veakoodid dokumenteeri alati ära. See on kasulik nii Sulle, kui teistele meeskonna liikmetele. Programmeerijate "käekiri" on suht erinev, seetõttu oleks suht halb lugeda teise inimese protseduuri (näiteks üks tiimi liige puhkab, või on haige), kus ca >4000 rida koodi, parem loeksin, et selline sisend ja selline tuleb väljund.

  • Soovitus: 6

    Hoidke projektipõhist veakoodide dokumenti; st. et kui üks programmeerija samas projektis loeb midagi failist ja saab vea, siis paneb ta koodiks 4, et faili lugemine ebaõnnestus; teise sama projekti mooduli programmeerijal tekib sarnane probleem ning tema paneb veakoodiks 84. Veakoodid ühtlustada !
    Veakoodid võiks olla programmides INT tüüpi, seda mälu kokkuhoiu tõttu.
    Andmebaasi protseduuridest saadavad veakoodid võiksid olla eraldi dokumenteeritud ja stringilised kujul ntx. ERR00005

  • Soovitus: 7

    Koodi kirjutamisel, kasutage treppimist; kommenteerige koodi maksimaalselt.

  • Soovitus: 8

    Koodis vältida liialt pikkade ridade tekkimist, kasutage reavahetusi.

  • Soovitus: 9

    Kasuta treppimisel tabulaatorite asemel tühikuid, tihti on nii, et teises masinas ei pruugi olla defineeritud tabulaator 8 tühikut.

  • Soovitus: 10

    Lisades andmebaasi protseduurile uued sisendid, paigutage need olemasolevate lõppu ning omistage neile vaikeväärtused. Sama tava kehtib ka andmebaasi tabelite kohta.

  • Soovitus: 11

    Võimaluse korral kasutage maksimaalselt andmebaasi serveri protseduure (stored proc); põhjuseid on mitmeid; ennekõike oleks märksõnad jõudlus ja turvalisus.

    Protseduuride puhul saadetakse üle võrgu ainult mõni rida koodi, võrgu koormus langeb. Andmebaasi serverid oskavad optimiseerida protseduurides olevat koodi; mis garanteerib ka kiiremaid pärinuid.
     
    Võrgu snifferitega ei ole siis ka võimalik SQL pakettidest välja lugeda tabelite ja väljade nimesid ! Protseduuridesse saate kirjutada ka väikese osa äriloogikast; juhul, kui peaks esinema päringus viga, saate selle kiiresti ära parandada, ilma, et peaksite hakkama kliendile kiiresti tarkvara uuendusi tarnima.
     
    Hästi disainitud andmebaasi süsteemis pole tava kasutajal üldse õigusi otseseks pöördumiseks tabelite poole, vaid kõik pöördumised käivad läbi serveri protseduuride (antud koht puudutab andmete riski jaotamist)

  • Soovitus: 12

    Programmid peaksid olema hästi konfigureeritavad, parim lahendus on, kui konfiguratsiooni muutujate väärtused küsitakse andmebaasi serverist.

  • Soovitus: 13

    Ennem, kui viid programmi sisse suured muudatused, salvesta arhiivi programmi hetke versioon ja lähtetekstid. Juhul, kui uues versioonis tekib mingi suurem viga, siis saad vana versiooni taastada ning kasutajad saavad oma igapäeva tööd jätkata (mitte itimehi kiruda). Kindel reegel on see, et tee nädalas korra või kaks oma töödest varukoopia kuhugi serverile (ideaallahenduses toimub koopiate tegemine igapäev), sest kui kõvaketas ikka tuttu läheb, on olukord suht karm.

  • Soovitus: 14

    Jõudes testfaasi peaks olema 3 järku:

    Programmeerija testib ise oma mooduleid/programmi,
    firma testiinsener koostab testide kriteeriumid ja sooritab testimise.
    Kui need eelnevad etapid on sooritatud, siis tuleb anda programm kasutajale testimiseks. Kogemustele toetudes on tava kasutaja parim testija, kuna ta ei mõtle tehniliselt.

    PS veebiprojektide puhul ärge unustage koormusteste (1-2 inimest pole veel koormus) !
     
    Kui tead, et veebiliidest võivad hakata korraga kasutama ca 400 kasutajat, siis tuleks teha koormustest ca ~ 800 kasutaja stiilis. Veebiprojektid on üldse omaette teema - ei tohi ära unustada närvilisi kasutajaid, kelle näpp F5 (Refresh) peal.

Ps minu juttu ei tasu 100% kullana võtta:)