Nepoužitý kód je horší než nečitelný kód

TLDR: Každý if, který napíšete, zvyšuje náročnost údržby kódu. Nepište zbytečný kód.

Na projektu se nám stala následující situace:

• Byznys požadoval podporu dvou čteček čárových kódů.
• Programátor napsal kód, který podporoval obě čtečky.
• Byznys se po několika letech rozhodl, že jednu ze čteček už nebude používat.
• Programátorům tento krok nikdo neoznámil a kód pro obě čtečky zůstal v aplikaci.
• Kód obou čteček se udržoval dál celé roky poté, co jedna z čteček přestala být potřeba.

Nepoužitému kódu se věnuje překvapivě málo pozornosti, i přesto, že:

Nepoužívaný kód je horší než nečitelný kód

• Když narazíte na nečitelný kód, víte, že je nečitelný, a víte, že ho můžete zrefaktorovat.
• Když narazíte na nepoužívaný kód, často ani nemáte tušení, že je nepoužívaný.

Jak by možná řekl moudrý grug:

Grug mít volba: nepoužitý kód nebo boj s T-rex.
Grug brát T-rex, aspoň T-rex vidět.

Jeden řádek kódu navíc nevadí

• Kód, který je 10 řádků dlouhý, je vždy jednodušší než kód, který má 10 000 řádků.
• Kód, dlouhý 1000 řádků, není o nic složitější než kód, který má 999 řádků.

Obě tyto informace platí pro drtivou většinu aplikací a dohromady vytvářejí zajímavý paradox. Jeden přidaný řádek kódu totiž působí neškodně a zdánlivě nic nekomplikuje. Postupem času se však takových řádků mohou nahromadit desítky, stovky i tisíce, a vy náhle zjistíte, že váš kód je ve skutečnosti komplikovaný. Krásně to ilustruje rčení death by a thousand paper cuts.

Je důležité znovu připomenout, že nepoužívaný kód jen tak nevidíte a nemůžete udělat jednoduchý refaktoring, kterým ho odstraníte.

Když pak porovnáme legacy systém a nový systém, vypadají nějak takhle:

Legacy systém

Nový systém

Oba ovladače dávají uživateli stejnou nebo velice podobnou funkcionalitu. Starý ovladač ale obsahuje hromadu tlačítek (řádků kódu), které prakticky nikdo nepoužívá.

Refactoring legacy systému pomůže jen částečně. Můžete třeba přidat popisky ke každému tlačítku ovladače (zdokumentovat kód), ale i tak bude výsledek stále horší než u nového systému.

Výsledkem je, že jakákoliv úprava legacy aplikace je mnohem složitější než úprava nové aplikace.

Jak nepřidat nepoužitý kód do aplikace

Neexistuje žádné univerzální pravidlo, které bych vám mohl říct. Vše záleží na situaci a kontextu. To nejlepší, co můžu udělat, je vám ukázat několik příkladů, jak nepoužitý kód vzniká, abyste si mohli na tento článek vzpomenout, když se dostanete do podobné situace.

Vyhýbejte se přehnané generalizaci kódu

My programátoři máme jistý fetiš pro psaní krásného obecného kódu, který řeší všechny možné i nemožné situace. V praxi je ale potřeba tento fetiš potlačit a psát kód, který je potřeba teď, protože je velice pravděpodobné, že obecnou variantu nikdy nebudeme potřebovat.

V praxi se mi jednou stalo, že programátor dostal zadáno vytvořit input pro vložení telefonního čísla. Programátor si požadavek přebral po svém a implementoval input pro vložení telefonu pro všechny země světa.

Možná si říkáte: „To je dobrý programátor, on přemýšlí dopředu.“ Skutečnost je ale taková, že firma, pro kterou jsme aplikaci vyvíjeli, už existuje asi 8 let a stále nemá ani plán expandovat do jiných zemí. Na druhou stranu obecný input v kódu stále leží a vždy, když je potřeba ho upravit, tak všem komplikuje život.

Nepište obecný kód zbytečně.

Preemptivně mažte nepoužívaný kód

Občas se stane, že naimplementujeme něco, co není potřebné. Když tato situace nastane, lidé často argumentují tím, že kód nebudeme mazat, protože se ještě někdy může hodit. Z mé zkušenosti můžu říct, že v drtivé většině případů to dopadne tak, že kód potřeba není.

Osobně se řídím následujícím pravidlem:

Radši kód smažu a po čase ho přidám zpět (pomocí git historie), než abych riskoval, že budu mít v aplikaci nepoužitý kód.

Snažte se co nejpřesněji zjistit požadavky uživatele

Tento problém se objevuje v mnoha situacích. Výčet některých z nich:

• Nevíme, co uživatel chce/potřebuje, pro jistotu naimplementujeme všechny možné varianty.
• Ještě předtím, než uživateli ukážeme naši aplikaci/feature, implementujeme zbytečnou funkcionalitu.
• Programátor naimplementuje něco, co se mu zdá důležité.
• Programátor implementuje něco, co si myslí, že se bude hodit.
• Někdo z byznysu vymyslí funkcionalitu, u které má pocit, že ji uživatel potřebuje.

V těchto situacích se vždy řiďte základními pravidly:

• Implementujte jen to, co je nutné.
• Co má a nemá aplikace dělat, zjistíme pouze experimentováním s reálnými uživateli.
• Programátor ani jiný zaměstnanec firmy není běžný uživatel systému a jeho představa o tom, co uživatel chce/potřebuje, je často zkreslená.
• Do chvíle, než naši aplikaci ukážeme uživateli, netušíme, co uživatel potřebuje/chce/bude používat.
• Naše domněnky o produktu jsou často špatné.

Jak najít nepoužívaný kód

Zjistit, že část kódu není používaná, je často heroický úkol. Obvykle máme následující možnosti:

Feature monitoring

První možností je monitorování feature. Jednoduše nastavíte metriky, které sledují, kolikrát byla feature za poslední den/měsíc/rok použita.

Problémem monitorování je, že některé features mohou být nepoužité celé měsíce, ale stále jsou potřeba. Příkladem mohou být kvartální nebo výroční reporty.

Dalším problémem je, že feature může být sice používaná, ale neznamená to nutně, že jsou používány všechny její části – viz úvodní příklad se čtečkami. Pokud bychom monitorovali pouze, zda jsou používány čtečky čárových kódů, vše vypadá OK, ale už se nedozvíme, že jedna ze čteček už není potřeba. Je tedy důležité a náročné zvolit správnou granularitu monitorování feature.

Scream test

Dalším způsobem, který je obecně známý, jsou scream testy. Feature jednoduše smažete, a pokud se někdo ozve, že danou funkcionalitu potřebuje, víte, že je potřeba.

Můžete zvolit i méně agresivní přístup – zobrazit hlášku „Tato funkcionalita bude odstraněna.“, přidat bug, který způsobí, že funkcionalita nefunguje, atd. Ve všech případech čekáte, jestli se někdo ozve a oznámí vám, že je potřeba feature obnovit/opravit.

Scream test je poměrně nepříjemný pro uživatele, a proto ho doporučuji používat pouze v nejnutnějších případech.

Pozorujte uživatele

Pokud je vaše aplikace používaná poměrně malou skupinou uživatelů (interní aplikace nebo jiné aplikace pro firmy), je možné jít za lidmi, kteří aplikaci používají, a sledovat, jak přesně vaši aplikaci používají, a nenápadně se ptát na funkcionalitu, kterou chcete smazat.

Mohlo by vás napadnout, proč se prostě nezeptat, jestli můžete feature smazat. V ideálním světě by to tak fungovalo, ale v realitě se pravděpodobně stane jedna z následujících věcí:

• Feature aktuálně není používaná a nikdo neví, že existuje. Vy jste na ni vaší otázkou upozornili a lidé si řeknou: „To je zajímavé, to bychom mohli použít,“ a odpoví vám, ať ji nemažete. Po týdnu na ni zase zapomenou a feature v aplikaci zůstane.
• Odpoví vám vedoucí týmu nebo jiný prostředník, který si myslí, že daná věc je používaná, ale ve skutečnosti není.
• Feature je sice používaná, ale asi tak jednou za rok, aby někomu ušetřila 2 minuty práce. V tomto případě vám okamžitě přijde odpověď: „Ano, to používáme.“

Mazání kódu

Když dojde na lámání chleba, je potřeba přesvědčit váš tým a také byznys o tom, že by bylo dobré feature smazat. Obvykle je to ale velice náročné.

Obecně je jednoduché vyčíslit, kolik stála implementace nějaké feature. Na druhou stranu je velice těžké vyčíslit, kolik peněz můžete ušetřit jejím smazáním. Na jedné straně tedy máte přesnou částku a na druhé straně máte nepřesné odhady.

Lidé se obecně v této chvíli rozhodnou iracionálně a rozhodnou se feature ponechat. Důvody jsou následující:

• Ambiguity Aversion – lidé preferují konkrétní číslo před nepřesným odhadem.
• Sunk Cost Fallacy – pokud jsme do něčeho investovali čas a peníze, často investujeme dále, i přesto, že to nedává smysl.
• Present Bias – lidé preferují to, co mají teď, předtím, co by mohli mít v budoucnu.
• Lidé (a programátoři) mají osobní vztah k feature a nechtějí ji smazat.
• Na úspěchu feature stojí kariéra lidí ve firmě.

Aby diskuse byla o něco racionálnější, je potřeba ve firmě vytvářet kulturu, ve které jsou lidé aktivně podporováni a motivováni k odstraňování nepotřebných věcí.

Závěr

• Nepoužité features zvyšují složitost kódu.
• Zjistit, která feature není používaná, je velmi těžké.
• Feature, která není používaná, je horší než nečitelný kód.
• Mazání kódu je často odmítané a setkává se s odporem.