Jeden z mých nejús­pěšnějších tweetů a přitom taková blbost. Takže asi stojí za rozepsání. Mám totiž za to, že existuje korelace mezi pořád­ku­mi­lov­ností a čistým kódem.

Občas vídám kód, z kterého je mi fyzicky nevolno. Ale člověk nějak musí zjistit, co je špatné. Abych citoval Ilust­ro­vanou knihu argumen­tač­ních faulů:

Číst o věcech, které bychom neměli dělat, je často užitečná a poučná zkuše­nost. Ve své knize O psaní píše Stephen King: „Nejlépe se člověk naučí, čeho se vyvaro­vat, při čtení špatné prózy.” Popisuje svou zkuše­nost se čtením obzvlášť špatného románu jako „literární ekviva­lent očkování proti nešto­vicím” [King]. Matematik George Pólya bývá citován, jak ve své přednášce o výuce matema­tiky prohlásil, že člověk musí nejen téma dobře chápat, ale také musí vědět, jak lze téma chápat špatně [Pólya].

Na pomoc si vezmu knihu Clean Code (Robert C. Martin) a doplním o pár svých postřehů. Měl jsem si ji přečíst na začátku své kariéry, ale na druhou stranu po deseti letech praxe ji dokážu o to víc ocenit. Je smutné, že principy v ní popiso­vané jsou často opomíjené.

Filozofie 5S

Hned v počátku knihy je zmiňo­vaná filozofie 5S, která se skládá z násle­dujících konceptů.

  • Seiri - rozděl. Klíčové je vědět, kde věci jsou. K tomu je potřeba vhodných jmen.
  • Seiton - setřiď. Kus kódu by měl být na místě, kde ho očekáváte, že ho naleznete. Pokud ne, tak refaktorujte, abyste ho tam dostali.
  • Seiso - uspořádej. Udržujte pracoviště čisté, bez překážejících drátů, mastnot, ústřižků a odpadků. Co se zaneřáděným kódem plným komentářů a zakomentovanými řádky, které zachycují historii nebo přání do budoucna? Zbavte se jich!
  • Seiketsu - standardizuj: Skupina se shodne na tom, jak udržovat pracoviště čisté.
  • Shutsuke - dodržuj. To znamená mít disciplínu následovat dané postupy, často reflektovat svou práci a být ochotný učinit změnu.

Citace z knihy

V knize jsem si hodně podtr­hával. Vybrané citace překládám. Začal bych jedním citátem, který nám sahá do svědomí, jelikož máme často tendence svádět příčiny projek­tových problémů na jiné lidi a vnější okolnosti, přičemž sami máme máslo na hlavě.

Nic nemá z dlouho­dobého hlediska tak ničivý efekt na projektu jako špatný kód. Špatné plánování lze změnit, špatné požadavky předělat, špatnou dynamika týmu opravit. Ale špatný kód hnije a kvasí a stává se neúprosným závažím, které táhne tým dolů.

Jack W. Reeves: Potře­bu­jeme dobrou archi­tek­turu (top level design), dobrou abstrakci (class design) a dobrou imple­men­taci (low level design)

Tady bych připomněl Ilju Kravala a jeho Analy­tické modelování infor­mač­ních systémů pomocí UML v praxi, kde razí rozdělování úrovně abstrakce na analy­tické modelování, návrh designu a kódování. Často se setkávám s tím, že se úrovně příliš míchají a přeska­kují. Programátoři mají tendenci přejít rovnou k imple­men­taci, čímž si zadělávají na vážný problém.

Čistý kód vždy vypadá, jako by ho psal někdo, komu na tom záleží.

Poměr mezi časem stráveným čtením a psaním bude dobře víc jak 10:1

Profe­sionálové používají svou sílu správně a píší kód, kterému mohou ostatní rozumět.

Formátování kódu je důležité. Je příliš důležité, abychom ho ignoro­vali a příliš důležité, abychom z něj udělali nábožen­ství. Formátování kódu je o komuni­kaci a komuni­kace je první byzny­sové přikázání profe­sionál­ního programátora.

Vracet z metod null je špatné, ale posílat null do metod jako parametr je horší.

Týmy si neuvědo­mují, že mít nepořádek v testech je stejné jako, ne-li horší než, nemít testy žádné.

Pokud necháte testy shnít, tak shnije i váš kód. Udržujte svoje testy čisté.

Abyste napsali čistý kód, musíte nejprve napsat špinavý kód a pak ho vyčistit.

Samozřejmě že špatný kód může být vyčištěn, ale to je velmi drahé.

Poznámky

Ještě pár poznámek bez doslov­ných citací. Není pochyb, že funkce s mnoha parametry je špatná, ale překva­pilo mě, že doporučuje i dyadické funkce (se dvěma proměn­nými) konver­tovat na monadické funkce (s jednou proměn­nou) a má pro to rozumné vysvětlení.

Kdo pamatu­jete třeba prehis­torické verze Hiber­nate, vzpome­nete si, že se to hemžilo checko­vanými výjim­kami, ale ty porušují open/c­losed princip. Však od nich jazyky (třeba Groovy, kde nemusíte dekla­rovat throws) a frameworky upouštějí (nahra­zují je runtime výjimkami).

Kniha mi přijde jako dobré výcho­disko pro nasta­vení standardů pro vaše code review. Ovšem ocenil bych, kdyby programátoři psali čistší kód a při code review byl větší prostor na byznys logiku či archi­tek­turu, a ne že se v šumu prkotin ztratí to důležité.

Kreativní nepořádek

Nevěřím na kreativní nepořádek. Jasně, že když jste upros­třed práce, na nějaký drobek nehledíte, ale v průběhu uklízím a nakonec uklidím úplně (manželka by samozřejmě měla výhra­dy). Když jsem v příspěvku Co se firmy můžou přiučit od armády 2 jen s mírnou nadsázkou zdůvodňo­val, proč je dobrý nápad, abychom nosili uniformy, dostal jsem slušnou čočku. Přesto znovu poukážu na armádu, tentokrát na dril a jejich ustlané postele nebo vyčištěné boty. V článku Trooping the Colour: 6 life lessons you can learn from the drill square píší:

V královské gardě je pozor­nost věnovaná detailu měřena leskem vašich bot.

Článek Scien­tists find physical clutter negati­vely affects your ability to focus, process information upozorňuje na výsledky výzkumu Prince­tonské univerzity.

Když je vaše prostředí plné nepořádku, tak ten chaos omezuje vaši schop­nost se soustře­dit. Nepořádek rovněž omezuje schop­nost mozku zpracovat infor­mace. Nepořádek vás činí roztěkanými a neschopné zpracovat infor­mace ve srovnání s uspořádaným, organi­zo­vaným a klidným prostředí.

Jestli máte lepší zdroje k tématice, šup s nimi do komentářů.

Historka z natáčení

Závěrem jedna (ne)ve­selá historka z natáč­ení. V duchu Joel Test 2.0 děláme statickou analýzu kódu v Sonaru. Jednou za čas se mění pravidla a jejich závažnost, k čemuž se mají šanci všichni vyjádřit. Strhla se celkem vášnivá debata nad pravidlem Unused imports (má ho Checkstyle i PMD) a hlavně nad nasta­venou závažností Critical, kvůli čemuž byly najednou takřka všechny projekty červené a releasy stopnuté. Domnívám se, že by se na úklid vynaložilo menší úsilí, než na danou diskuzi, obzvlášť když zrovna tohle umí zametat samo IDE. Tím jsem chtěl ilust­ro­vat, že čistota není programátory žádaná. A to ani taková, kterou lze snadno zajis­tit. Což teprve nějaké pokroč­i­lejší postupy jako konver­tování dyád na monády.

A proč že potřeba odstraňovat nepoužité importy? V knize Clean Code se píše:

Speci­fické importy jsou tvrdá závislost…

A jak že to dopadlo? Závažnost se snížila a nepoužité importy zůstaly. Pak už jen krůček k nepoužitým závis­lostem Mavenu a rázem má war 80 MB.

Související