V předešlém článku jsme hovořili o chybách špatně umístěného kódu. Naše úvahy se opíraly o jednoduchý princip rozdělení aplikace na tři vrstvy, vrstva “levá” (anonymní klient), naše vrstva kódu a “pravá” vrstva kódu, kterou náš kód používá:
Také jsme si vysvětlili první možnou chybu, kdy se kód, který správně patří “nalevo”, umístí do naší vrstvy a tím se naše vrstva zašpiní (tvorba slepenců, kočkopsů apod.).
Nyní si vysvětlíme druhou možnou chybu – umístění kódu do naší vrstvy namísto “vpravo”, kam správně patří. Podle obrázku kód tedy nepatří do střední vrstvy B (kam je chybně umístěn), ale patří do vrstvy “napravo”, tj. do vrstvy C a tento kód má být námi zavolán (tj. použit). Namísto toho jej umístíme chybně jako „rozbalený na plocho kód“ do naší vrstvy B. Tím, že jej umístíme do B, kód ztrácí svou identitu (tj. nedá se zavolat). Například takto vznikají dlouhé „nestrukturované metody“, které provádějí v jedné sekvenci kódu spoustu věcí, kdy vše probíhá v jednom plochém kódu, aniž by se kód rozdělil do částí ve vrstvě C, odkud se dá použít i jiným klientem, než námi.
Příklad: V metodě spouštěné na událost ukončení inicializace (loadování) pluginu je třeba kódem zjistit, zda byla již vydána nová verze pluginu a případně to nahlásit uživateli. Napíše se tedy kód, který přečte z textového souboru na webu verzi programu (tam je umístěna verze vždy aktuální) a porovná tuto načtenou verzi s tou, kterou má plugin u sebe v nastavení uvnitř programu. Pokud zjistí rozdíl, nahlásí existenci nové verze včetně rozdílu. Když bychom tuto sekvenci kódu umístili do naší metody inicializace pluginu jako sadu po sobě jdoucích rozbalených řádků (např. jako 7 řádků kódu pod sebou), tak je to špatně, i když to bude fungovat. Správně to má být „zabaleno“ do jiného kódu (např. nakódováno do třídy a poté použito jako objekt), tj. má to být umístěno do vrstvy C a tam tento kód má být z našíí vrstvy zavolán např. metodou objektu. Při krokování programu se toho ale moc nezmění, pouze při debugování se vnoříme „Step Into“ do vrstvy C. Nejenom že přehlednost programu se zvýší, ale daný kód pro zjištění nové verze má již svou identitu, dá se zavolat i odjinud, například na stisknutí tlačítka uživatelem. Mimochodem jeho testování je také díky identitě tohoto kódu o mnoho snazší.
Poznámka: Programátoři mnohdy postupují tak, že takovýto kód nejprve rozchodí jako plochý v daném místě a poté provedou refactoring a “vytknou” jej do “pravé” vrstvy C a použijí.
Tuto situaci umístění kódu do vrstvy C vystihuje obrázek:
Vzato přísně logicky, obě dvě chyby (uvedeny zde jako chyba “levá” a “pravá”) jsou stejné podstaty a dají se chápat jako důsledek porušení jednoho principu a to principu jedné odpovědnosti (alias porušení “čisté” opětovné použitelnosti, tj. porušení “re-use bez balastu”), pouze pohled z naší vrstvy je relativní: Při posuzování umístění kódu směřujeme pohled buď doleva ke klientovi našeho kódu anebo doprava ke kódu, jehož my jsme klientem.
Závěr
Největší záludností špinavého kódu je ta skutečnost, že kód je sice funkční, ale vnitřně špatný a nepřehledný. Ne vše, co funguje, je dobře. Pro velmi rychlé posouzení špinavosti kódu lze projít daný otevřený kód dané vrstvy a ověřit si, že pro něj neustále platí princip jedné odpovědnosti, tj. re-use bez balastu. Ověříme si to rychle tak, že každá část otevřeného kódu skutečně patří do tohoto místa a nemá být ani nalevo (nepatří ke klientovi našeho kódu) a nemá být ani napravo (tj. nemá se zabalit a zavolat).
Prosperující SW firma hledá analytiky a JAVA programátory v okolí Hradce Králové
V případě zájmu pište na e-mail objects@object.cz
