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:

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. +more 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. +more 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. +more 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í. +more ** 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ě. +more 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. +more 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. +more 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. +more 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

Guy L. Steele, Jr. +more & Richard P. Gabriel The Evolution of Lisp, [url=http://citeseer. ist. psu. edu/steele93evolution. html]citeseer. ist. psu. edu[/url] * Brian Foote and Joseph Yoder, [url=http://www. laputan. org/mud/]Big Ball of Mud[/url] Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, září 1997.

Kategorie:Návrhové antivzory