Vágnost významu slova modularita jej přímo předurčuje k ovládnutí marketingových materiálů. Modularita je sice všude, ale všude taky znamená něco jiného. Rozplést tenhle chuchvalec myšlenek a přijít na to, co modularita ve skutečnosti je, mi trvalo mnoho let a sepsat to dalších mnoho měsíců. Tato první část se věnuje ekonomické motivaci k modularitě, ta druhá pak technické záludnosti modularity.
V první řadě je potřeba rozebrat ten základní automatický předpoklad, že modularita je dobrá. Je naprosto zásadní zeptat se proč, protože odpověď je jednak překvapivě netriviální a jednak není jen jedna. A od toho se odvíjí většina nepochopení. Takže modularita je dobrá, protože podporuje:
- Přepoužitelnost: jeden modul je možné použít ve více projektech a tím sdílet náklady na jeho vývoj a údržbu.
- Zaměnitelnost: je možné vyměnit jeden modul za jiný, pokud má stejné rozhraní. Díky tomu je možné si operativně vybírat podle druhotných vlastností modulů (cena, přidaná hodnota…), co se nám zrovna hodí.
Často se jako první objeví argument, že modularita hlavně podporuje dobrou organizaci kódu. To je zavádějící, protože dobrá organizace je sice důležitá, ale nejtěžší problémy modularity jsou esenciální, nikoli akcidentální. Rozdělení projektu do modulů nemusí přinést žádnou z výše uvedených výhod ani žádný z níže popsaných problémů. “Modulární monolit” (častý případ Maven reactor projektů) je proto pro tento článek nezajímavý.
Kontrakty
Alfa a omega modularity jsou kontrakty mezi moduly. Že se na kontrakty dá dívat ze dvou stran je na technologické úrovni dobře známé a podchycené. Tímto článkem se snažím rozšířit povědomí o této dualitě i mezi netechnické účastníky softwarového vývoje. Ekonomické výhody modularity se totiž odvíjí od toho, že kontrakt je “vlastněn” jednou ze stran (ve smyslu “je vytvořen a měněn” jednou ze stran kontraktu):
- Přepoužitelnost: kontrakt definuje dodavatel služby. To je případ API různých služeb a sdílených knihoven.
- Zaměnitelnost: kontrakt definuje odběratel služby. To je případ architektonického principu dependency inversion.
Přímo ze slov “dependency inversion” je vidět, že výhody modularity jsou podmíněny závislostí v jednom nebo druhém směru. To mimo jiné znamená to, že obou výhod nelze běžně dosáhnout zároveň - z definice by to byl buď obecný standard nebo monolit (zajímavou souvislost těchto termínů nechávám k zamyšlení). Směry závislostí jsou tyto:
- Přepoužitelnost: odběratel závisí na dodavateli služby.
- Zaměnitelnost: dodavatel závisí na odběrateli služby.
To sice nemá dopad na matematickou podstatu algoritmizace jako takové, ale má to zásadní dopad na průběh vývoje a údržby software, protože tato závislost určuje, čí zájmy kontrakt přednostně sleduje.
- Přepoužitelnost: kontrakt sleduje zájmy dodavatele služby. V reálném světě to je například když telefonní operátor změní podmínky služby (např. zavede FUP apod.). Zákazníkům se to nemusí líbit, ale protože břímě spojené se změnou operátora je na jejich straně, motivuje je to změně se podřídit.
- Zaměnitelnost: kontrakt sleduje zájmy celku, ve kterém je modul použitý. V reálném světě to je příklad veřejných výběrových řízení, kdy se vypíše specifikace požadované služby/produktu. Pak se jednak vybírá nabídka s nejnižší cenou a jednak je možné dodavatele jednoduše nahradit někým z ostatních zájemců, kdyby se pokoušel měnit kontrakt pro celek nevyhovujícím způsobem.
Podstata sdělení této kapitoly je, že technický význam kontraktu algoritmu nelze oddělit od významu kontraktu pro organizaci jeho výroby. To se nejvíc projevuje právě na modularitě. Co za důsledky to má v praxi?
- Architekti milují dependency inversion. Jsou odpovědní za funkčnost a stabilitu celku a proto volí organizační princip, který k tomu přirozeně konverguje.
- Manažeři milují OOP, protože ač je to z hlediska matematické podstaty algoritmizace mizerný nástroj, modelování kontraktů podle reálného světa je v něm “first class citizen”.
- Modularita není problém, který lze “vyřešit” technicky. Neexistuje jedno optimální řešení, protože optimum se odvíjí od stavu sociální konstrukce okolo vyvíjeného produktu, která je unikátní pro každý produkt i každou jeho životní fázi.
- Modularita ve vší obecnosti proto je a zůstane extrémně složité téma. Jediné řádové zjednodušení může plynout z vypuštění některého základního aspektu. Například termíny “accretion” a “breakage”, které používá Rich Hickey ve své fantastické přednášce o problému kompatibility modulů, jsou podle mého názoru relativní k oněm dvěma ekonomickým přínosům, které modularita může přinést. Co je v přepoužitelnosti accretion, je pro zaměnitelnost breakage a naopak. Rich navrhuje výrazné zjednodušení, ale je potřeba nezapomenout, že to je za cenu omezení modularity pouze na přepoužitelnost. A podobně je to s každým “zázračným” řešením.