Přidej si svou IT školu do profilu a najdi spolužáky zde na síti :)

STUPID - Špatné praktiky vývoje softwaru

Návrh Best practices STUPID - Špatné praktiky vývoje softwaru

Unicorn College ONEbit hosting Tento obsah je dostupný zdarma v rámci projektu IT lidem. 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í.

Singleton a koťátka

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.


 

 

Článek pro vás napsal David Čápka
Avatar
Jak se ti líbí článek?
7 hlasů
Autor pracuje jako softwarový architekt a pedagog na projektu ITnetwork.cz (a jeho zahraničních verzích). Velmi si váží svobody podnikání v naší zemi a věří, že když se člověk neštítí práce, tak dokáže úplně cokoli.
Unicorn College Autor se informační technologie naučil na Unicorn College - prestižní soukromé vysoké škole IT a ekonomie.
Miniatura
Předchozí článek
Praktiky SOLID
Miniatura
Všechny články v sekci
Best practices pro návrh softwaru
Aktivity (2)

 

 

Komentáře
Zobrazit starší komentáře (22)

Avatar
David Čápka
Tým ITnetwork
Avatar
David Čápka:3. října 8:55

Čas programátora stojí minimálně 40k/měsíc, čas stroje nestojí skoro nic. Proto se optimalizace tak nehrotí. Programátoři téměř vždy v práci nestíhají dělat vůbec funkcionalitu, natož aby ji zbytečně optimalizovali, aby měla na 1 TB disku 15 MB místo 50 MB. K čemu by to bylo dobré? Buď můžeš dát lidem produkt s 10 funkcemi nebo produkt s 5 funkcemi, který zabírá méně na disku, ale jim je to jedno. Když budeš takhle přemýšlet, tak tě konkurence brzo zničí.

Odpovědět  +3 3. října 8:55
Miluji svou práci a zdejší komunitu, baví mě se rozvíjet, děkuji každému členovi za to, že zde působí.
Avatar
eaktivo
Člen
Avatar
Odpovídá na David Čápka
eaktivo:3. října 9:10

Veď to je ten problém, že nie je na nič čas. Spraví sa hardware a ovládače sa odflakajú - potom to tak aj funguje. Všetko sa robí rýchlo, na nič nie je čas a potom to tak aj vyzerá. Optimalizácia nie je len o mieste, ale aj o rýchlosti. Priklad dobrej optimalizácie je napríklad Unreal engine. Keď hrám hodinu hru v Unreal engine, tak na grafickej karte sa ani neroztočí ventilátor. Ked pozriem CryEngine, tak po 5 minutách už možem variť čaj na grafickej karte. Pritom výsledok je v podstate ten istý. Nie celkom, lebo ten unreal ide na 120 fps a ten CryEngine na 50 fps ledva. Tomu sa hovorí rozdiel v optimalizácii. Ďalšia vec je - kupím si hardware a za pol roka už nejdem zohnať ovládač - nie je čas. Len Apple má na to čas, aby upravil iOS pre každý hardware. Android ? Kúp si nový telefón, keď chceš nový Android. :-D Všetko sa tlači do GB a GHz. Som zvedaví, že dokedy. :-D

 
Odpovědět 3. října 9:10
Avatar
Luboš Satik Běhounek
Autoredaktor
Avatar
Odpovídá na eaktivo
Luboš Satik Běhounek:3. října 9:23

Čas jsou peníze a optimalizace SW může trvat klidně násobně víc času, než jeho napsání, přitom je klidně možný, že to zrychlíš jen o pár procent.

Kdo by chtěl zaplatit za SW 3x víc jen aby mu to ve výsledku běželo třeba jen o 20% rychlejc, čehož si ani nevšimneš, dokud to exaktně nezměříš?

Proto se u komerčních aplikací obvykle optimalizuje až ve chvíli, kdy něco běží znatelněji pomalu, než by asi mělo.

Odpovědět  +3 3. října 9:23
https://www.facebook.com/peasantsandcastles/
Avatar
Michal Štěpánek:3. října 9:45

Trošku se mi zdá, že mícháš dohromady dva pojmy "optimalizace kódu" a "optimální psaní kódu". Podle mě jsou to dvě různé činnosti. Pod pojmem "optimalizace kódu" já rozumím takovou činnost, při které si sednu nad už hotový kód, nebo jeho část a začnu vymýšlet, co bych na něm mohl upravit nebo změnit, aby to fungovalo o trošku lépe. A to si myslím, že myslel David Čápka větou

neměli zabývat optimalizací kódu, dokud to není opravdu potřeba.

Odpovědět  +1 3. října 9:45
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
eaktivo
Člen
Avatar
Odpovídá na Luboš Satik Běhounek
eaktivo:3. října 9:54

Problém tohoto sveta je kvantita na úkor kvality. Každý chce rýchlo niečo spraviť a rýchlo zhrabnúť prachy - pritom cena produktu neodzrkadluje kvalitu. Nie je to len problém IT a programovania, ale všetkého. Apple je na prvom mieste v ziskoch. Možno si ľudia radsej priplatia za tú optimalizáciu a čas, ktorý nad ňou tí programátori strávia ako za rýchlo spravené dielo na ktorého opravy, update a upgrade nie je čas. Google vyhľadávač je celý postavený na optimalizácii, inak by nebol tam kde je. A oplatilo sa investovať do viac ľudí, do času, do vývoja, do optimalizácie. A pokračujú v tom ďalej....

 
Odpovědět  +1 3. října 9:54
Avatar
eaktivo
Člen
Avatar
Odpovídá na Michal Štěpánek
eaktivo:3. října 9:59

Dokončím kód a optimalizujem na rýchlosť a miesto.
Keď mam Microkontroler ktorý ma 2 kB pamäti a 1 Mhz, tak mi je každý bajt a každý Hz cenný. Keď máš 16 GB a 4 Ghz, tak sa to dá nagrcať hocijako a väčinou to pojde ok. Čím viac GB, tým sa to lepšie predáva.

 
Odpovědět 3. října 9:59
Avatar
Marian Benčat
Redaktor
Avatar
Odpovídá na eaktivo
Marian Benčat:3. října 10:19

"premature optimalizace" , víš co je asi, že? :-) NIKDY se neoptimalizuje a ani neoptimalizovalo v prvé řadě.. Ani ten demoscénař nepsal tu svoje demo na ZX hned na první dobrou. Máš vesměs 2 druhy softwaru:

  1. Standardní komerční software, který dělá 95% trhu a kde se neoptimalizuje vůbec, nebo až po dokončení funkcionality, kdy se detekují pomocí profileru hotspoty a ty se pak řeší.
  2. SW kde potřebuješ výkonu hodně a ten je na takové úrovni, že už na úrovni ani těch algoritmů toho tolik nevyřešíš, takže jdeš níže - začneš u datových struktur, takže si nepouštíš ani časový profiler, ale spíše CPU profiler a sleduješ CPU countery.. především pak práci s pamětí, branche prediction atp.. Na tomto základě pak především optimalizuješ uskladnění dat v paměti atp.

Ty změny jsou ale pak tak strašně moc markantní, že u tohoto SW se vyplatí skutečně už hned od začátku ho navrhovat tak, aby byl optimální a tady se už při vývoji optimalizuje, protože pak by to bylo později mnohem náročnější.


Z výše zmíněného jsem ti chtěl nenápadně nastínit, že dnešní technologie už jsou na takové úrovni a rychlosti, že to brzdí výkon není práce CPU, která se právě optimalizuje a optimalizovala na microcontrollery, ale I/O operace - tedy práce s pamětí.. A tu budeš řešit u komerčního SW až po dokončení funkcionalit, když tě to HODNĚ pálí.. a pak u zbylých 2% SW typu GPGPU výpočtů, náročných CPu výpočtů atp.

Odpovědět  +3 3. října 10:19
In Smalltalk, everything is an object, In Clojure, everything is a list, In Javascript, everything is fucking mistake
Avatar
eaktivo
Člen
Avatar
Odpovídá na Marian Benčat
eaktivo:3. října 10:55

Stale mi vrta v hlave ta optimalizacia. Na Amige (7,14 Mhz, 1 MB RAM) som mal operacny system na troch 880 kB disketach a tento Windows ma 4 GB a po nainstalovani 15 GB. Viditelny rozdiel vidim len v rozliseni a pocte farieb. Kompresiu / dekopresiu medii a 3D robi dnes uz v podstate hardver, tak mi je ten rozdiel neprimerany. Podla mna by mal mat v dnesnej dobe tak 250 MB max. bez tych omalovanok (medii) co su nevyhnutne. Chyba tam optimalizacia ak aj v inych softveroch ako je Adobe, Autodesk, ...

 
Odpovědět 3. října 10:55
Avatar
Luboš Satik Běhounek
Autoredaktor
Avatar
Odpovídá na eaktivo
Luboš Satik Běhounek:3. října 11:16

Na Amige (7,14 Mhz, 1 MB RAM) som mal operacny system na troch 880 kB disketach a tento Windows ma 4 GB a po nainstalovani 15 GB. Viditelny rozdiel vidim len v rozliseni a pocte farieb. Kompresiu / dekopresiu medii a 3D robi dnes uz v podstate hardver, tak mi je ten rozdiel neprimerany. Podla mna by mal mat v dnesnej dobe tak 250 MB max. bez tych omalovanok (medii) co su nevyhnutne.

Jaka optimalizace podle tebe ve Win chybi? Problem s velikosti Win je ten, ze spousta DLL je tam ulozena ve vice verzich kvuli zpetny kompatibilite.

250MB? Jen samotny dllka v System32 maj u me pres 4 GB, jak tohle chces nacpat do 250 MB?

Ono kdyz si neuvedomujes, co vsechno ve Win je, tak se nedivim, ze ti prijdou velky - ono teda samozrejme velky jsou a zmensit by jeste urcite sly, ale nemysli se, ze i o to se vyvojari nesnazej :)

Odpovědět  +1 3. října 11:16
https://www.facebook.com/peasantsandcastles/
Avatar
David Čápka
Tým ITnetwork
Avatar
David Čápka:3. října 11:59

Souhlas, taky díky za diskuzi. K těm třídám mimo root, často ve složce "vendor", jsou často menší a i kdyby tam bylo hodně zanoření se závislostmi, rozdíl je v tom, že ty knihovny píšeš/používáš obvykle hned pro několik projektů. Typicky si tedy člověk postahuje hotové knihovny, napíše si jednu nebo 2 specifické. Tam máš pravdu, že závislosti předá ručně. Vše ostatní pak jede přes DI. U hodně projektů člověk ani žádný kód mimo root nepíše, prostě to jen poskládá. Když už bych psal nějakou knihovnu, tak bych to předal ručně, nějaké Singletony by mohly být špatně použité někým, kdo tu knihovnu nezná a vytáhne si nějakou instanci, kterou si vytáhnout neměl. Myslím, že jsme se tedy shodli :)

Odpovědět 3. října 11:59
Miluji svou práci a zdejší komunitu, baví mě se rozvíjet, děkuji každému členovi za to, že zde působí.
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

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