Stupid - Zlé praktiky vývoja softvéru

Už sme si spomenuli tie najlepšie praktiky pre vývoj softvéru, ktoré združuje akronym SOLID. Podobne existuje aj opačný akronym, STUPID, ktorý naopak združuje zlé praktiky, chyby a antipatterny, ktoré vedú k plytvaniu časom i peniazmi.

Skupina praktík STUPID sa skladá z:

• S ingleton
• T ight coupling
• U ntestability
• P remature optimization
• Aj ndescriptive naming
• D uplication

Poďme si ich podrobne vysvetliť.

S ingleton

STUPID začína hneď kontroverzným jedináčikom, ktorý stredne pokročilí programátori používajú a tí profesionálni ho zatracujú.

Pokiaľ chcete porušovať LOĎ, Shy, Loose coupling, DIP, IOC a rad ďalších dobrých praktík, zdieľajte závislosti vo svojich aplikáciách cez antipattern Singleton. Aj napriek prvotnej senzáciu okolo Singleton sa časom zistilo, že to nie je v jadre nič iné, než globálna premenná, oblečená do pekného obleku návrhových vzorov. A samozrejme prináša tie isté problémy ako globálne premenné. Závislosti budú globálne dostupné a budú porušovať základné stavebné kamene OOP. Bohužiaľ počúvam, že sa na Singleton pýtajú na niektorých pracovných pohovoroch a snáď je aj používajú vo svojom firemnom softvéru. Buďte teda u pohovorov opatrní a snažte sa vzor popisovať neutrálne. Vo svojich aplikáciách ho ale nepoužívajte, na svete bude menej zla.

T ight coupling

Vytvárajte vo svojej aplikácii tesné väzby, napr. Vyššie zmienenými Singleton alebo zlým rozdelením zodpovednosti, nepoužívajte GRASPO, a vaše aplikácie čoskoro prestanú byť udržiavateľné. Tesné väzby označujú situáciu, keď je medzi dvoma triedami zbytočné množstvo väzieb. Celý systém je potom zviazaný tesne k sebe, čo znemožňuje jeho modifikáciu a sťažuje jeho rozširovanie. Opakom je už mienený loose alebo low coupling, kedy sú komponenty voľne pospájané len niekoľkými väzbami medzi sebou.

U ntestability

Netestovatelnost sa týka automatických testov, o ktorých tu máme v každom jazyku samostatný kurz. Ak ste sa o testovaní ešte nezaujímali, určite ho odporúčam naštudovať. Pri návrhu tried je nutné pamätať na to, že triedu bude pravdepodobne niekto testovať. Je to podobné, ako by sme mali pamätať na to, že triedu bude pravdepodobne niekto dediť. Ak budete používať napr. Singleton, znemožníte mockování závislostí a tým aj testovanie triedy (to je mimochodom jedna z ďalších nevýhod jedináčikov). Ďalším problémom môže byť nedodržiavanie SRP, kedy sú metódy príliš dlhé, vágne, napr. Namiesto vrátenia hodnoty niečo vypisujú a podobne. Takýto kód potom testovať moc dobre nedá. A komplexné aplikácie bez aspoň základných automatických testov je v dnešnej dobe už nekonkurenčné, náklady na ručné testovanie reálnych komerčných aplikácií sú pomerne vysoké. Veľa informácií o testovaní vrátane úvodu a zoznamu výhod a nevýhod pozri už spomínané kurzy o testovaní v sekciách príslušných programovacích jazykov tu na sieti.

P remature optimization

Čo sa týka predčasné optimalizácia, možno ste niekedy počuli vetu

Premature optimization is the root of all evil

, Teda "Predčasná optimalizácia je koreňom všetkého zla." Poučka hovorí, že by sme sa nemali zaoberať optimalizáciou kódu, kým to nie je naozaj potrebné. Pomerne krátko sa totiž zistilo, že pred nasadením aplikácie do reálneho produkčného prostredia nemôžeme tušiť, ako na tom bude výkonovo a kde presne budú tzv. Úzke hrdlá (bottlenecks). Optimalizácie, ktoré programátori zbrklo vykonali, v úplnej väčšine iba spomalili vývoj a v praxi neboli potreba alebo neboli dostatočné. Poučka nám ale naopak nehovorí, aby sme písali nekvalitné kód. Mali by sme voliť správne a jednoduché riešenia a až pri ich zlyhaní vykonať optimalizáciu. Pri jednom z našich IT školení prebehla zaujímavá diskusia o voľbe dátových typov premenných. Jeden z účastníkov sa ohradil prečo odporúčame používať pre reprezentáciu všetkých čísel typ int, keď napr. Vek užívateľa nebude nikdy viac ako 150 rokov a int má rozsah do 2 miliárd. Našou odpoveďou bolo, že int v pamäti zaberá akurát 32 bitov a preto s ním 32/64 bitový procesor pracuje oveľa rýchlejšie, než by pracoval s 8 bitovým menším typom. Táto optimalizácia by teda bola pravdepodobne výkonovo nevýznamná a podobné rozmýšľania zbytočne plytvá vývojový čas. O optimalizácii aplikácií pripravujeme samostatný kurz.

Aj ndescriptive naming

Jedna zo začiatočníckych chýb je používanie Nič nehovoriace názvov, či už premenných, metód alebo tried. Mať triedu v množnom čísle nedáva zmysel, metóda by mala byt v rozkazovacom spôsobe, teda utoc(), nie utok(), čo by sa mohlo pliesť s premennou utok, obsahujúce napr. Útok bojovníka v HP. Niektorí premenné pomenúvajú dokonca ako x, pole, text a podobne. Alebo ako foo, bar, baz, to bohužiaľ nájdete napr. V ukážkach oficiálneho PHP manuálu. Premenné pomenovávame vždy podľa toho, čo obsahujú, je to úplne jednoduché pravidlo a prekvapivo veľa začiatočníkov ho porušuje. Správne názvy sú teda napr. soucet, nadpis, faktury. Zamyslite sa nad rozdielom medzi poľom pole a poľom faktury. Kolekcia pomenovávame samozrejme v množnom čísle, pole faktúr sa nesmie menovať ani faktura ani f. Používanie podobných identifikátorov extrémne spomaľuje vývoj aplikácie a keďže programátori bežne poberajú až 4 priemerné platy, značte zdražuje aj jej vývoj.

D uplication

O duplicitným kódu a DRY sme už hovorili. Akýkoľvek kód, ktorý sa nachádza v rovnakej alebo aj len podobné podobe na viacerých miestach aplikácie, je automaticky zle a predstavuje potenciálnu hrozbu pre ďalší vývoj. Nielen, že sa v dlhom kóde zle orientuje, ale každú zmenu je nutné vykonať na všetkých výskytoch podobného kódu a to je priestor pre zanesenia chýb. Vyčerpávajúci príklad ako možno kód skrátiť pomocou pravidiel DRY a KISS nájdete v článku Základné best practices pre návrh softvéru.

V nasledujúcom kvíze, Kvíz - Best practices pre návrh softvéru, si vyskúšame nadobudnuté skúsenosti z kurzu.