none dzio.sk
nový "Jeruzalem"
sk
|
en
|
tT

novinka dňa

Nový designer apiek ;)

24.03.2024 07:38
Začal SOM pracovať na designeri apiek (zatiaľ pre web, neskôr pre android a windows) 😉

Už to vie konfigurovať stránky s obsahom 😉

Aj nejaké témy sú tam 😉

Kukni na https://www.madzi.sk/ 😉


všetky novinky skryť novinku
pre správne fungovanie tejto stránky, potrebujem používať cookies...

Skúsenosti z vývoja
best practices...
01.04.2022 17:52

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
xxx
veľkosť 44 259 B
vygenerované za 0.10102 s
vytvoril dzI/O 2015 - 2024
táto stránka musí používať koláčiky aby mohla fungovať...
zobrazená 247 x
všetky 1 831 810 x
ip 3.80.211.101

podpora

stránka má príjem jedine od dobrovoľných podporovateľov
za mesiac 2024 / 3, bolo na reklamu kliknuté 3,69 € (30 klikov), z toho dnes 0,15 € (1 klik), ďakujem...
prosím, podpor stvoriteľa
prevodom na účet:
SK41 1100 0000 0026 1872 7972
SWIFT: TATRSKBX
názov účtu:
Dziak Maroš, Ing.
banka:
Tatra banka, a.s.
Hodžovo námestie 3
811 06 Bratislava 1
none
cez paypal:
cez viamo:
none
cez donater:
poštou:
Ing. Maroš Dziak
Budovateľská 67
075 01 Trebišov
Slovensko, EU
a teraz pozri, kto prispel:
online používatelia (1)
madzi @ facebook
MaDzi
lipka @ facebook
Lipka
help @ facebook
Help
zmysel života @ facebook
Zmysel života
kniha života @ facebook
Kniha života
documentor @ facebook
Documentor
univerozum @ facebook
Univerozum
zdieľaj
štatistiky
TOPlist TOPlist TOPlist