Skúsenosti z vývoja

best practices...

v2.18 01.04.2022 17:48

Prvé kroky
1. pred začatím prác na akomkoľvek systéme je vhodné urobiť si predstavu o systéme
2. na vytvorenie tejto predsavy a v konečnom dôsledku základného modelu systému slúžia pomocné otázky:
3.a. aké entity (objekty) sa vyskytujú v systéme a ako sa volajú
3.b. aké sú dané entity (aké majú vlastnosti)
3.c. čo robia dané entity (aké majú metódy)
3.d ako entity medzi sebou interagujú
Agilná metodika
1. ja agilný prístup k vývoju nazývam aj metóda POKUS-OMYL - lebo pokúšame sa dosiahnuť cieľ ( = POKUSY), dovtedy kým ho nedosiahneme - pri tomto procese samozrejme získavame medzivýsledky, s ktorými nemusíme byť spokojní ( = OMYLY)
2. v prvom rade je potrebné stanoviť cieľ
3. následne iteračným spôsobom smerujeme k cieľu
4. vytvoríme prvú verziu podľa najlepšieho vedomia a svedomia s ohľadom na stanovený cieľ
5. prvá verzia väčšinou nebýva celkom dokonalá
6. nasleduje zhodnotenie verzie - a zistenie nedostatkov resp. vylepšení, ktoré by bolo vhodné riešiť
7.a. ak existujú nedostatky a vylepšenia, vytvoríme ďalšiu verziu a ideme na bod 6
7.b. ak sme s danou verziou spokojní, máme hotový produkt = dosiahli sme cieľ
Jednoduchosť riešenia
1. najjednoduchšie riešenia sú tie najlepšie - z pohľadu urdžateľnosti, prenositeľnosti, rýchlosti pochopenia atď.
2. zároveň je menší potenciál na vznik logických chýb pri riešení
3. chybám z blbosti sa samozrejme nevyhneme asi nikdy
Jednoduchosť hierarchie tried
1. ak sa to preženie s robustnosťou hierarchie tried, celé riešenie sa stáva málo prehľadné a pochopiteľné a prenositeľné
2. preto je vhodné zachovávať čo najmenšiu možnú pyramídu tried
Štandartný postup pri riešení úloh
1. rieši sa konkrétna situácia / úloha
2. ak sa rieši podobná situácia / úloha, treba zvážiť, či netreba vytvoriť nadtriedu nad aktuálnou triedou, s tým, že do spoločnej triedy sa presunú spoločné funkcionality
Prístupy k návrhu hierarchie tried
1. pri návrhu hierarchie tried sa dá postupovať princípom ZHORA NADOL a ZDOLA NAHOR
1. princíp zhora nadol znamená, že top trieda, z ktorej sú odvodené ďalšie triedy obsahuje spoločné vlastnosti všetkých tried danej časti hierarchie
2. príklad: každý pes vie štekať ale nie každý pes vie stáť na zadných
3. preto schopnosť štekať bude v top level triede a schopnosť stáť na zadných bude až v odvodenej triede konkrétneho druhu psa
1. princíp zdola nahor znamená, že top trieda, z ktorej sú odvodené ďalšie triedy obsahuje všetky použiteľné vlastnosti všetkých tried danej časti hierarchie
2. príklad: každý pes bude mať schopnosť štekať ale aj stáť na zadných
3. ale nie každá odvodená trieda bude používať všetky schopnosti, ktoré má každý pes
1. konečné riešenie sa získava kombináciou týchto dvoch prístupov k veci
2. použije sa prístup, ktorý je v danej chvíli najvýhodnejší
Duplikáty kódu
1. snažiť sa vyhýbať duplikovaniu kódu v maximálnej možnej miere
2. ak máš nutkanie vykonať copy & paste nejakej časti kódu, tak zváž, či nie je vhodné zadefinovať nejakú metódu alebo dokonca celú novú triedu
Štruktúrovanie toku kódu
1. osvedčilo sa mi pridávať nejaké voľné miesto v kóde, keď sa to hodí
2. ak nejaké časti kódu spolu súvisia, tak ich držím pokope
3. ak chcem oddeliť nejaké logické celky, tak medzi ne vkladám prázdne riadky
4. kód sa tým stáva viac prehľadnejším a vzdušnejším
Komentovanie
1. programátor by mal byť schopný vydedukovať čo robí aplikácia priamo z kódu
2. ale pri niektorých zložitejších konštrukciách je vhodné popísať čo daný kód robí
3. dôležité však je dbať na to aby komentáre boli vždy aktuálne, ak už sa v kóde vyskytujú
4. v zásade som za to aby bola každá trieda, atribút a metóda okomentovaná aspoň pár riadkami, samozrejme pri metódach je povinnosť okomentovať parametre
5. jednak z toho získame dokumentáciu generovanú prostriedkami vývojového prostredia a jednak uľahčíme prácu tomu, kto sa s daným kódom ešte len oboznamuje
Naming convention
1. názvy tried, metód a atribútov by mali čo najvýstižnejšie vyjadrovať o čo ide podľa biznis logiky