Implementovat jednoduchý blog dokáže kdekdo. Zvolíte některý z populárních frameworků, vytvoříte formulář s pár políčky, jako jsou název a text článku, přidáte wysiwyg editor, uděláte hezkou fasádu a voilà! Blog je na světě. Ale bohužel ne vždy to jde takhle jednoduše…
Aplikace, na jejichž vývoji jsem spolupracoval, se vyvíjí roky. Během té doby se do nich začlení hodně nových požadavků, a občas se dokonce může úplně změnit obchodní model a s ním i chápání toho, co je klíčovou částí systému. Jednou jsme například pracovali na realitním portálu, na kterém lidé sami inzerovali své nemovitosti. Po dvou letech vývoje jsme se však zaměřili na prodej přes agenty a původní koncept jsme zcela opustili. Všechny tyto změny zvyšují komplexitu.
Začínáme
Ale pojďme pěkně popořadě. Když začínáte projekt takříkajíc na zelené louce, máte většinou docela jasnou představu, co má aplikace umět. Sepíšete si případy užití, entity, vazby mezi nimi (prostě model) a vše naimplementujete. Výsledný kód je čitelný a vše funguje dobře. Vývojáři jsou pyšní na své nové dítě a klient je spokojený. Mise splněna.
Pokud je produkt úspěšný, tak přichází požadavky na nové funkcionality. Termíny jsou neúprosné a vy hledáte snadná řešení. Ohýbáte původní návrh, množství kódu roste a čitelnost klesá. Často mluvíte o rostoucím technickém dluhu. Trvá-li tento stav delší dobu, implementace nových požadavků je stále náročnější, klient je nespokojený, protože odhady jsou příliš vysoké, vývojáři jsou frustrovaní, a někteří dokonce z firmy odcházejí.
V čem je tedy zakopaný pes?
- Vývojáři používají jiný jazyk než business. Dostanete zadání, vymyslíte si entity a vrhnete se do implementace. Až časem zjistíte, že to, čemu říkáte transakční log, nazývají lidé z businessu kreditový účet, a to, čemu říkáte vytvoření uživatele, oni označují pojmem registrace. Váš kód sice funguje, ale není z něj poznat, jaký business problém řeší. Nováčci jsou zmatení a potřebují překlad mezi tím, co slyší na poradách, a tím, jak je to pojmenované v kódu.
- Nevěnování dostatečné pozornosti návrhu. Začnete s MVC architekturou a všechen kód boucháte do jednoho monolitického modulu, ve kterém používáte stejné entity (např. Produkt) napříč celým systémem. Po čase jsou tyto entity obrovské a nepřehledné a vy se do nich bojíte zasahovat, protože i malá změna může vést k neočekávaným chybám v rozličných částech systému, o kterých mnohdy ani nevíte, že je máte. Na psaní testů, které by Vám kryly záda, samozřejmě nebyl čas.
- Míchání doménové logiky a technických aspektů. Potřebujete nahradit platební bránu, ale kód obsluhující tu starou je tak propleten s kódem řešícím doménovou logiku, že není snadné starou bránu vykostit. A když už se Vám to konečně podaří, tak si nejste jistí, jestli jste nezanesli do doménové logiky nechtěné změny.
- Neporozumění businessu, ve kterém se pohybujete. Máte na starost návrh systému, ale jste odstíněni od lidí, kteří znají business. Dostáváte zadání, která jsou spíše popisem řešení, ze kterého není zřejmé, s jakým problémem se vlastně potýkáte. Například: „Každý den o půlnoci vyexportujte do excelu seznam objednávek.“ Zadání splníte, ale budoucí změny budou obtížně implementovatelné, protože řešení nereflektují reálné procesy.
To jsou problémy, které jsem identifikoval během své ne zase tak dlouhé kariéry PHP vývojáře já. Jsem si jistý, že dokážete doplnit další. Snažil jsem se naučit těmto problémům předcházet, což mě dovedlo k Domain-Driven Designu (DDD), jemuž se již nějakou dobu věnuji.
Závěrem bych vás tedy rád pozval, abyste se ke mně připojili ve studiu DDD v následujících článcích. Společně se naučíme, co DDD vůbec je a jak s jeho pomocí tvořit lepší aplikace.
Sdílet článek