STUPID - Špatné praktiky vývoje softwaru

Vydávání, hosting a aktualizace umožňují jeho sponzoři.
Již jsme si zmínili ty nejlepší praktiky pro vývoj softwaru, které sdružuje akronym SOLID. Podobně existuje i opačný akronym, STUPID, který naopak sdružuje špatné praktiky, chyby a antipatterny, které vedou k plýtvání časem i penězi.
Skupina praktik STUPID se skládá z:
- Singleton
- Tight coupling
- Untestability
- Premature optimization
- Indescriptive naming
- Duplication
Pojďme si je podrobně vysvětlit.
Singleton
STUPID začíná hned kontroverzním jedináčkem, který středně pokročilí programátoři používají a ti profesionální jej zatracují.

Pokud chcete porušovat LoD, Shy, Loose coupling, DIP, IoC a řadu dalších dobrých praktik, sdílejte závislosti ve svých aplikacích přes antipattern Singleton. I přes prvotní senzaci kolem Singletonu se časem zjistilo, že to není v jádru nic jiného, než globální proměnná, oblečená do hezkého obleku návrhových vzorů. A samozřejmě přináší ty samé problémy jako globální proměnné. Závislosti budou globálně dostupné a budou porušovat základní stavební kameny OOP. Bohužel slýchávám, že se na Singletony ptají na některých pracovních pohovorech a snad je i používají ve svém firemním softwaru. Buďte tedy u pohovorů opatrní a snažte se vzor popisovat neutrálně. Ve svých aplikacích jej ale nepoužívejte, na světe bude méně zla.
Tight coupling
Vytvářejte ve své aplikaci těsné vazby, např. výše zmíněnými Singletony nebo špatným rozdělením odpovědnosti, nepoužívejte GRASP, a vaše aplikace brzy přestanou být udržovatelné. Těsné vazby označují situaci, kdy je mezi dvěma třídami zbytečné množství vazeb. Celý systém je potom svázaný těsně k sobě, což znemožňuje jeho modifikaci a znesnadňuje jeho rozšiřování. Opakem je již míněný loose nebo low coupling, kdy jsou komponenty volně pospojované jen několika vazbami mezi sebou.
Untestability
Netestovatelnost se týká automatických testů, o kterých zde máme v každém jazyce samostatný kurz. Pokud jste se o testování ještě nezajímali, určitě jej doporučuji nastudovat. Při návrhu tříd je nutné pamatovat na to, že třídu bude pravděpodobně někdo testovat. Je to podobné, jako bychom měli pamatovat na to, že třídu bude pravděpodobně někdo dědit. Pokud budete používat např. Singletony, znemožníte mockování závislostí a tím i testování třídy (to je mimochodem jedna z dalších nevýhod jedináčků). Dalším problémem může být nedodržování SRP, kdy jsou metody příliš dlouhé, vágní, např. místo vrácení hodnoty něco vypisují a podobně. Takový kód potom testovat moc dobře nelze. A komplexní aplikace bez alespoň základních automatických testů je v dnešní době již nekonkurenceschopná, náklady na ruční testování reálných komerčních aplikací jsou poměrně vysoké. Spoustu informací o testování včetně úvodu a výčtu výhod a nevýhod viz již zmíněné kurzy o testování v sekcích příslušných programovacích jazyků zde na síti.
Premature optimization
Co se týká předčasné optimalizace, možná jste někdy zaslechli větu
Premature optimization is the root of all evil
, tedy "Předčasná optimalizace je kořenem veškerého zla." Poučka
říká, že bychom se neměli zabývat optimalizací kódu, dokud to
není opravdu potřeba. Poměrně krátce se totiž zjistilo, že před
nasazením aplikace do reálného produkčního prostředí nemůžeme
tušit, jak na tom bude výkonově a kde přesně budou tzv. úzká
hrdla (bottlenecks). Optimalizace, které programátoři zbrkle
provedli, v naprosté většině pouze zpomalily vývoj a v praxi nebyly
potřeba nebo nebyly dostatečné. Poučka nám ale naopak neříká, abychom
psali nekvalitní kód. Měli bychom volit správná a jednoduchá řešení a
až při jejich selhání provést optimalizaci. Při jednom z
našich IT školení proběhla zajímavá debata o volbě datových typů
proměnných. Jeden z účastníků se ohradil proč doporučujeme používat
pro reprezentaci všech čísel typ int
, když např. věk
uživatele nebude nikdy více než 150 let a int
má rozsah do 2
miliard. Naší odpovědí bylo, že int
v paměti zabírá akorát
32 bitů a proto s ním 32/64 bitový procesor pracuje mnohem rychleji, než by
pracoval s 8 bitovým menším typem. Tato optimalizace by tedy byla
pravděpodobně výkonově nevýznamná a podobné rozmýšlení zbytečně
plýtvá vývojový čas. O optimalizaci aplikací připravujeme samostatný
kurz.
Indescriptive naming
Jedna ze začátečnických chyb je používání nicneříkajících
názvů, ať již proměnných, metod nebo tříd. Mít třídu v
množném čísle nedává smysl, metoda by měla byt v rozkazovacím způsobu,
tedy utoc()
, nikoli utok()
, což by se mohlo plést s
proměnnou utok
, obsahující např. útok bojovníka v HP.
Někteří proměnné pojmenovávají dokonce jako x
,
pole
, text
a podobně. Nebo jako foo
,
bar
, baz
, to bohužel naleznete např. v ukázkách
oficiálního PHP manuálu. Proměnné pojmenováváme vždy podle toho,
co obsahují, je to naprosto jednoduché pravidlo a překvapivě mnoho
začátečníků jej porušuje. Správné názvy jsou tedy např.
soucet
, nadpis
, faktury
. Zamyslete se nad
rozdílem mezi polem pole
a polem faktury
. Kolekce
pojmenováváme samozřejmě v množném čísle, pole faktur se nesmí jmenovat
ani faktura
ani f
. Používání podobných
identifikátorů extrémně zpomaluje vývoj aplikace a jelikož programátoři
běžně pobírají až 4 průměrné platy, značte zdražuje i její
vývoj.
Duplication
O duplicitním kódu a DRY jsme již mluvili. Jakýkoli kód, který se nachází ve stejné nebo i jen podobné podobě na více místech aplikace, je automaticky špatně a představuje potenciální hrozbu pro další vývoj. Nejen, že se v dlouhém kódu špatně orientuje, ale každou změnu je nutné provést na všech výskytech podobného kódu a to je prostor pro zanesení chyb. Vyčerpávající příklad jak lze kód zkrátit pomocí pravidel DRY a KISS naleznete v článku Základní best practices pro návrh softwaru.
Komentáře


Zobrazeno 10 zpráv z 32. Zobrazit vše