STUPID - Špatné praktiky vývoje softwaru

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ž nekonkurences­chopná, 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.