Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 6. kapitola: Ukázka vyčištění špinavého kódu

Na ukázkovém příkladu z předešlého článku si nyní ukážeme konkrétní praktické postupy řešení situací s nečistým kódem. Ukážeme si efektivní použití testů na čistotu kódu a také postup, jak se nečistého kódu zbavit.  

Nejprve si u příkladu z předešlého článku zodpovězme otázku: Proč vlastně autor umístil (chybně) počet kusů do druhu zboží? Vedlo jej k tomu slovní spojení znějící takto: „navrhněte množství jako aktuální počet kusů daného druhu zboží“. Z toho usoudil (chybně), že počet kusů daného druhu zboží je vlastností daného druhu zboží (protože to tak na první poslech zní).

Je třeba si ale uvědomit, že původní „čistý“ číselník druhů zboží sloužil jen a pouze k tomu, aby si do něj jiné entity „ukazovaly“ odkazem. Znamená to, že by se měl používat v situaci, když se potřebujeme vyjádřit ve smyslu „něco má vlastnost odkaz na druh zboží“ (Řádek faktury obsahuje tento Druh zboží apod.). Když analyzujeme dané slovní spojení „množství jako počet kusů daného druhu zboží“ tak přesně tato zásada “ukazování si do druhu zboží”, tj. chceme říct daného druhu zboží, tam zřetelně zaznívá.

Do Druhu zboží se má ukazovat (je použit a nepoužívá), tj. Množství není vlastností Druhu zboží, ale naopak, Druh zboží je vlastností Množství. Správně má být tedy vztah obráceně: „Druh zboží (přesněji odkaz na něj) je vlastností Množství zboží na skladě“, např. takto:

obr.1: Vztah mezi Množstvím na skladě a Druhem Zboží správně, tj. je dodržen smysl života číselníku Druhu zboží

Všimněme si, že v tomto modelu je dodržen smysl číselníku Druhu zboží, chceme říct ‘tohoto Druhu zboží‘, tak si do něj ukážeme.

Jednoduché testy na čistotu kódu

Jak tedy rychle a bezpečně poznáme, že původní řešení není dobře (i když funguje)?

Jednoduše to zjistíme tímto postupem:

1. Položíme si základní otázky testující opětovnou použitelnost bez malusu (tj. bez záporného bonusu),

2. poté se podíváme, kde je kód umístěn,

3. na základě tohoto zjištění zformulujeme odpovědi na otázky z bodu 1,

4. posoudíme odpovědi z titulu logiky věci a zdravého selského rozumu, odpovědi nesmí být nesmysly.

Zkusme tedy tyto testy přímo na našem příkladu:

První otázka: Kde budeme hledat daný kód, když se řekne, že je tam chyba?

V našem případě se tato otázka formuluje konkrétně takto: Máme chybu v počtu kusů na skladě. Kde budeme hledat kód, abychom to opravili? Odpověď: V číselníku Druhu zboží… aha, něco je špatně…

Druhá otázka: Co musíme změnit, překopat (který kód musíme otevřít a přeprogramovat), když přijde požadavek na změnu?

Takže například nechť přijdou se změnou: „Jsme se rozrostli a máme dva sklady, změňte prosím program pro dva sklady“.
Odpověď: „To nám neříkejte ani ze srandy, my musíme překopat číselník druhu zboží.“
„Ale my mluvíme o skladu!“
„Ano, ale my musíme překopat číselník druhu zboží.“
„To máte nějaké divné…“
…a budou mít pravdu.

Pokud se podíváme na správné řešení na předešlém obrázku, pak tyto otázky dostávají správné odpovědi, což je přímý důsledek dodržení čistoty kódu. Například při požadavku na vícero skladů se model změní takto:

obr 2.: Změna skladu je změnou skladu, nikoliv Druhu zboží

Důsledky chybného řešení

Zbytečný zásah do funkčního kódu 

Oproti čistému řešení se přidáním počtu kusů do druhu zboží úplně zbytečně otevřel již existující dobře chodící kód číselníku druhu zboží a naprogramovala se v něm zbytečně další funkcionalita, což znamená potencionální chybu a nutnost testovat skrz naskrz něco, co vůbec nebylo nutné měnit a testovat.

Umím si představit zvolání dost „rozhořčeného“ vedoucího projektu: „Proč jste proboha tuto agendu otevírali a přeprogramovali, když to vůbec nebylo nutné a navíc je to hrubá chyba?“

Jakékoliv změny jsou velmi drastické

Umístění prvku z vyšší vrstvy do nižší vrstvy a tedy umístění kódu někam, kam nepatří, má velmi nepříjemný vliv na další vývoj systému při změnách resp. iteracích agilního vývoje. Výsledkem je neustále otevřený kód, který se neustále překopává (a testuje) s adrenalinovými detektivkami vyhledávání, kde vlastně ten kód je, když není tam, kde má být.

Příště:

V příštím článku tohoto miniseriálu se budeme se věnovat jedné vysoce praktické věci: Ze zásad tvorby čistého kódu vyplývají určité konkrétní postupy návrhu kódu v určitých konkrétních situacích. Protože se tyto konkrétní situace při kódování opakují, vznikla tak konkrétní doporučení, jak tyto konkrétní situace řešit. Tato doporučení se nazývají jako „principles“ (principy ve smyslu silného doporučení) a de facto se jedná o vzory (vzor chápeme jako opakující se řešení opakujícího se problému).

Poznámka: Například v našem chybném modelu s množstvím na skladě v druhu zboží došlo k porušení principu zvaného „princip jedné odpovědnosti“.

Principy mají pro dobré zapamatování svoje zkratky, jako SOLID, PINI, DRY, ADP, OCP. Z těchto principů vyplynula další praktická doporučení (tzv. best practices).


Nepřehlédněte zajímavé školení se slevou!

Chcete se důkladněji seznámit s problematikou tvorby čistého kódu a nasazení Design Patterns? Zúčastněte se školení
Čistý návrh v OOP, best practices a Design Paterns” v Brně 27.6-29.6.2017, termín garantován
přednáší RNDr. Ilja Kraval, autor článku

  • Využijte množstevní slevy 3 + 1 (každý čtvrtý účastník má účast zdarma).
  • Přihlaste se a použijte kód na slevu ve výši 20%, který zní SLEV_27. Platnost kupónu do 12.6.2017 !
  • Obě slevy lze kombinovat.

Blíže o školení viz zde


Líbil se vám článek?

Dejte mu like na postu LinkedIn zde.

Categories

About the Author:

správce a majitel Serveru objektových technologíí http://www.objects.cz

0 Comments
0 Pings & Trackbacks

Leave a Reply