Mis on arendamisreeglid (design guidelines) ja milleks neid üldse vaja?
Ühtsed arendamisreeglid ja nende reeglite järgimine ettevõttes tagavad kvaliteetsema programmikoodi, mis järgib arendamise häid tavasid, mustreid jne (muidugi on see kood sama kvaliteetne kui arendusreeglid :) ). Lisaks tagab ühtse koodi arendajate jaoks - neil on kergem seda lugeda ja sellest aru saada. Ka on see kasulik uutele arendajatele, kes ei tea ja tunne häid praktikaid ning võtteid veel ja vajavadki just niisugust juhendit.
Arendamisreeglid saavad olla platvormist ja keelest sõltumatud (üldisemad) või sõltuvad. Tihedamini on nad siiski platvormist sõltuvad ja võtavad arvesse just selle platvormi ja keele eripärasid ning praktikaid (just nendest ma räägingi siin).
Kust leida mõnda näidet?
Kunagi aasta-poolteist tagasi moodustasin ma arendamisreeglid Vita jaoks. Ja siis oli palju abi ühest raamatust - "Framework design guidelines: conventions, idioms and patterns for reusable .Net libraries". Antud raamat on kirjutatud .Net -i raamistiku arendajate poolt ning selles tutvustatakse reegleid, mida kasutati .Net -i raamistiku arendamisel ja miks just neid kasutati ning antakse soovitused enda rakenduste (taaskasutatavate koodiosade) arendamiseks. Igatahes mina nautisin seda raamatut :). Samad reeglid, mis on raamatus võite leida ka MSDN -st.
Kuigi usun, et internetist leiaks mitmeid valmis arendusreeglite dokumente, mida aluseks võtta, soovitan siiski teile ka ühe omalt poolt :)
On olemas üks ettevõte nimega IDesign ja nad on publitseerinud avalikkusele kasutamiseks arendamisreeglid (lisaks kõigele muule kasulikule, mis nad on avalikustanud). Võite leida selle dokumendi siit.
Aga, arendajal ei pruugi alati meeles olla need reeglid?
Tõsi see on, kellel meist seisaks kõik meeles, mis teha on vaja? Aga pole hullu, enam ei peagi kõikke meeles pidama ja ka harjumuste muutmine on tehtud lihtsamaks.
Selleks on vaja kahte sammu.
Samm 1:
Võtta kasutusele Visual Studio 2005 plugin Code Style Enforcer. Antud vahend annab märku kui eksitakse defineeritud reeglite vastu.
Järgnev pilt demonstreerib, kuidas eksitakse privaatse muutuja defineerimisel.
Ja kuidas aitab antud plugin parandada viga.
Reeglid mida järgida on defineeritud XML failis ja on väga lihtne muuta vastavalt sisemistele arendamisreeglistele. Lihtsalt defineerid rule -e.
Konfiguratsioonifaile on mitu ja üks nendest näeb välja järgmine.
Note: selleks et lihtsustada XML -i failide muutmist soovitan alla tõmmata vastava XSD faili (antud juhul see) ning paigutada "C:\Program Files\Microsoft Visual Studio 8\Xml\Schemas" kataloogi. Kui XSD on paigutatud sinna ja failis on viide antud XSD -le namespace -s, kasutab Visual Studio selles kirjeldatud reegleid ja enforcib neid. Ehk teil on tunduvalt kergem XML -s korrektset konfiguratsiooni kirjutada.
Samm 2:
Avada Visual Studio -s projekt ning valida see projekt. Teha parem klõps selle peal ja valida Properties. Avanenud aknas on vasakul loetelus valik Build. Valida "Treat warning as errors" loetelust valik All.
Antud valik tagab, et kui on mõni warning üleval, siis lahendust ei kompileerita, ennem kui on kõik warningud ka korda tehtud.
Nüüd ei saa arendaja isegi warninguid ignoreerida ja üks tüüpiline asi, mida warninguna näidatakse on XML -i kommentaarid koodis, mis on hädavajalikud ja ei võta nii palju aega arendaja poolt.
XML -i kommentaaride kaudu dokumenteerimist lihtsustab vahend nimega GhostDoc :) Soovitan kõigile! Armusin sellesse vahendisse juba ammu!
Hääd reeglite kasutusele võttu :)