Velká hrouda bahna

Velká hrouda bahna je softwarový systém, který postrádá promyšlenou architekturu. Přestože z inženýrského hlediska je tento přístup nevhodný, takové systémy se běžně v praxi vyskytují kvůli obchodním tlakům a obměnám vývojářů. Proto bývá tento přístup označován jako návrhový anti-vzor.

V počítačových programech

Termín velká hrouda bahna byl v roce 1997 popularizován Brianem Footem a Josephem Yoderem ve stejnojmenném článku, který tento termín definuje takto:

„Velká hrouda bahna je nahodile strukturovaná, rozlehlá, nedbalá, poslepovaná a posvazovaná džungle špagetového kódu. Tyto systémy vykazují nezaměnitelné znaky neregulovaného růstu a opakovaných účelných oprav. Informace jsou sdíleny libovolně mezi vzdálenými částmi systému, často to zachází až ke globalizaci téměř všech důležitých informací nebo jejich duplikaci. Celková struktura systému možná nebyla nikdy dobře definována. Pokud byla, možná zerodovala k nepoznání. Programátoři s kouskem citu pro architekturu se straní těchto bažin. Pouze ti, kdož se nezajímají o architekturu a nejspíše se cítí pohodlně v setrvačnosti dennodenní práce na záplatování děr v těchto selhávajících příkopech, jen ti jsou spokojeni s prací na takových systémech.“

Systémy velké hroudy bahna bývají obvykle vyvíjeny v dlouhém časovém období se zapojením různých jednotlivců pracujících na nejrůznějších kouscích a částech. Systémy vyvinuté lidmi s neformální architekturou nebo programovací cvičení často upadá k tomuto vzoru. Foote a Yoder nepřisuzují „velkou hroudu bahna“ univerzálně programování, upozorňují, že tento vzor převažuje, protože funguje – alespoň ve chvíli dokončení vývoje. Nicméně programy užívající tento vzor se stávají noční můrou pro údržbu. Programátoři, kteří řídí projekt velké hroudy bahna, jsou velmi podněcováni, aby jej studovali a pochopili jeho úspěchy, a použili je jako volný základ pro formální množinu požadavků pro dobře navržený systém, který může původní projekt nahradit. Technologické posuny – např. z modelu klient-server na webový model nebo ze souborových záznamů na databázové záznamy – mohou poskytnout mnoho dobrých důvodů pro nový začátek.

Anti-vzory

Tento návrhový anti-vzor je ve skutečnosti vnímán spíše jako super vzor, který bývá výsledkem používání některých nebo všech z následujících anti-vzorů, tak jak je definují Foote a Yoder:

• Kód na jedno použití (angl. throwaway code)
  • Rychle napsaný „špinavý“ kód, který překračuje dobu použití, na kterou byl dimenzován. Je špatně dokumentovaný nebo není dokumentovaný vůbec.
  • Letité používání a udržování jednoduchého programu „na jedno použití“ plodí velkou hroudu bahna.
  • „Funguje to, tak proč to opravovat?“

• Postupný růst (angl. piecemeal growth)
  • I dobře navržené systémy mají tendenci s časem podléhat strukturální erozi. Ta postihuje úspěšné systémy, které svým úspěchem přitahují požadavky na množství změn v čase. Může to vést i k totálnímu zapletení systému a nucenému opuštění jeho architektury. Čím hůře je systém pochopitelný, tím větší jsou náklady na změny v něm.

• Udržet to funkční (angl. keep it working)
  • Strategie malých lokálních změn a oprav, kdy jádro může být zdravé, ale okrajové části se zanáší. Růst je inkrementální.

• Stříhání vrstev (angl. shearing layers)
  • Části systému se vyvíjí s různou rychlostí, tím se prohlubuje rozdílnost těchto částí a dochází k emergenci trvalé rozdílnosti abstrakce.

• Zametání pod koberec (angl. sweeping it under the rug)
  • Obestavování nefunkčních částí.
  • Ultimativní řešení typu „když to nebude fungovat, zkusme to jinak“.
  • Často výsledná neudržovatelnost vyvrcholí v totální rekonstrukce, ale většinou jen lokálního charakteru

• Rekonstrukce (angl. reconstruction)
  • Kompletní přestavba systému.

Architektura a síly

V počátcích vývoje je často architektura ve stínu funkcionality. Architektonické pohnutky přicházejí většinou později – pozdě. Množství systémů, které jsme schopni vystavět, může být větší než množství systémů, které jsme schopni vystavět elegantně.

Vznik velké hroudy bahna způsobují převážně tyto síly:

• Čas
  • Někdy prostě musí přijít deadline
  • Náklady, time-to-market, um programátora
  • Architektura by měla být dlouhodobá záležitost
  • Nevyzrálá architektura je lepší než žádná
  • Přirozená evoluce a migrace
• Náklady
  • Složité vyhodnocení návratnosti investice do promyšlené architektury
  • Často vyhrává, co nejrychlejší postup na trh
  • „Pokud si myslíte, že dobrá architektura je příliš drahá, zkuste špatnou architekturu.“
• Zkušenosti / Dovednosti
• Viditelnost
  • Jak programátoři pohlíží na architekturu
• Složitost
  • „Program je ošklivý, protože problém je ošklivý“
• Změny
• Měřítko
  • „Dobré nápady nelze vždy škálovat“

Předcházení zabahnění

Nejdříve se zaměřte na funkce a funkčnost a teprve poté na architekturu a výkon. Zkuste extrémní-párové programování, okamžitá vzájemná kontrola vaše programy dovede ke kráse. Entropii v softwaru lze vyhnat refaktoringem. Refaktoring může odvrátit přeměnu ve velkou hroudu bahna. Zaměřte se na architektonický refaktoring, tedy věnujte zvýšenou pozornost struktuře.

V programovacích jazycích

V diskuzi o programovacím jazyce Lisp se používá výraz velká hrouda bahna v jiném významu. V tomto případě k popisu tvárnosti systému Lispu. V Lispu je obecně možné:

• Jednoduše psát makra, která dávají kontrolu na syntaxí jazyka, takže notace se více blíží doméně použití
• Použití datově orientovaného programovacího stylu
• Spouštět části programu při kompilaci místo za běhu
• Uložit systémový obraz modifikované implementace Lispu pro budoucí použití

Programovací jazyk Forth bývá také popisován jako hrouda bahna protože také má mnoho těchto vlastností. Joel Moses možná také stvořil tento termín v letech 1970: „APL je jako nádherný diamant – hladký, krásně symetrický. Ale nemůžete k němu nic přidat. Pokud zkusíte přilepit jiný diamant, nedostanete větší diamant. Lisp je jako hrouda bahna. Přidejte víc a je to stále hrouda bahna – pořád to vypadá jako Lisp.“ Joel Moses však silně odmítá, že toto řekl. Prohlašuje, že Lisp nazval pytlem fazolí, protože se stále vrací do původního tvaru.

Ve skutečném světě

Tento návrhový anti-vzor v obecnějším pojetí popisuje mnoho systémů formovaných ve skutečném světě. Bezesporu nejzajímavějším příkladem jsou asi indické slamy, které vznikají přesně v duchu tohoto přístupu. Zdá se, že všichni vědí, že je to špatný nápad, ale stejně síly umožňují jejich emergenci. Slamy jsou většinou z běžných levných materiálů a k jejich výrobě stačí jen obyčejné nástroje a žádné významné dovednosti stavitele. Není dbáno na infrastrukturu, jelikož ta vyžaduje koordinaci, kapitál a specializované zdroje, výbavu a dovednosti. Dochází k minimálnímu plánování nebo regulaci růstu. Slamy se prostě objeví, tam kde jsou potřeba pro přebytek nekvalifikované pracovní síly a nedostatek kapitálových investic. Slamy tak zabezpečují okamžitou místní potřebu bydlení prostým snesením dostupných zdrojů týkajících se problému. Cokoliv architektonicky dokonalejšího je luxus, který musí počkat.

Odkazy

• Návrhový vzor
• Programování

Reference

V tomto článku byl použit překlad textu z článku Big ball of mud na anglické Wikipedii.

• Guy L. Steele, Jr. & Richard P. Gabriel The Evolution of Lisp, citeseer.ist.psu.edu
• Brian Foote and Joseph Yoder, Big Ball of Mud Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, září 1997