V dnešním článku bych rád volně navázal na předchozí dva blogy, ve kterých jsme se s vámi podělili o několik našich nových poznatků získaných na odborné konferenci PHPCE 2017, která se konala ještě v listopadu minulého roku v Polsku.
Během jedné z přednášek byl prezentován celkem zajímavý pohled na současný vývoj v programovacím jazyce PHP. Autor v ní poukázal na zásadní rozdíly ve vnímání tohoto vývoje samotnými vývojáři a manažery. Jako příklad uvedl, že jazyk PHP v očích některých manažerů zřejmě nepatří mezi nejnovější a “nejsexy” programovací jazyky (jako např. jazyk Go nebo Ruby), z řídícího hlediska je však důležité zejména to, že tento jazyk je časem ověřený, poměrně jednoduchý, dá se rychle naučit a programuje v něm velké množství lidí.
7 rad, jak možno zlepšit vývoj softwaru
Za velmi užitečnou zároveň považuji druhou část zmíněné přednášky, ve které zaznělo 7 rad, jak možno zlepšit vývoj softwaru. Pojďme si je stručně zrekapitulovat:
- Kolektivní znalosti (Collective knowledge). Tyto poznatky by podle autora neměly být koncentrovány jen u jednoho vývojáře. Ideálním řešením je seznámit s nimi všechny vývojáře participující v týmu. Vhodné je podle jeho slov používat například párové programování, code reviews a jim podobné nástroje. Jejich výhodou je i to, že pomáhají odstraňovat chyby, které dělá každý vývojář a ve finále kvalitnější kód.
- Testy. Nezbytnou součástí každého dobrého kódu je i testování. Na jedné straně je to automatizované testování, které se spouští před nasazením každé změny softwaru do produkce. Akceptační testy, které umožňují otestovat vyvinutou funkcionalitu jako celek (např. umožňují zjistit, zda funguje přidání produktu do nákupního košíku a dokončení nákupu). Na druhé straně je to regresní testování, jehož cílem je otestovat, zda jsme jednou změnou nezpůsobili úplně nové chyby.
- Menší častější releasy (Small releases). Cílem tohoto postupu je místo provádění velkých změn realizovat sérii menších změn.
- Snažit se předvídat chyby (anticipate errors). Faktem je, že chybám ve vývoji softwaru nelze úplně předejít. Je proto důležité vždy počítat i s tím, že chyby se vyskytnou a předem se na tyto situace připravit.
- Opatrnost (awareness, benefits vs. risks). Každé rozhodnutí je spojeno s určitými riziky, které jsou na druhé straně vyvážené určitými benefity. Vždy je proto důležité zvážit, zda jsme ochotni podstoupit určité riziko s vidinou získání určitého benefitu. Typická situace může vypadat i následovně: Vyplatí se v pátek odpoledne nasadit změnu na e-shop? Benefit - např. vyšší prodejnost, riziko - co když změna nasazená v pátek odpoledne úplně odpálí e-shop a o víkendu to nebude mít kdo opravit?
- Monitorování (monitoring). Toto pravidlo je velmi důležité a říká nám o tom, že vždy je potřeba monitorovat co nejvíce možných parametrů – například, zda prudce neklesá počet uživatelů, jaký je počet chyb a různé jiné. Jen na základě důsledného monitoringu je totiž možné včas reagovat na případné vzniklé problémy.
- Neustálé zlepšování (improve). Sedmá zásada nám říká o tom, že celý vývojový proces je potřeba neustále zlepšovat a zdokonalovat. Je to neustálý cyklus inovací a zlepšení, kterými reagujeme na nové trendy i vývoj na trhu.
Další zajímavou dilemu přinesla přednáška Why is CRUD a bad idea, z které vzešla polemika o tom, zda je vhodnější používat Anemic Domain Model nebo Rich Domain Model. Je to téma, které se poměrně často objevuje v různých odborných diskusích. Někteří vývojáři se přitom přiklánějí spíše k prvnímu modelu, jiní se řadí mezi příznivce druhého variantu. Podívejme se nyní na některé základní fakty v obou uvedených případech:
Anemic Domain Model
- tento model slouží hlavně jako prostředek na získání dat, neobsahuje však žádnou logiku,
- slouží jen jako objektově-relační mapovač, neřeší však konkrétní chování,
- logika proto musí být umístěna v Controllerech, Managerech, Helperech,
- z pohledu objektově-orientovaných principů je to anti-vzor,
- jeho výhodou je však menší komplexita tříd a metod,
- například při připočítávání peněz k bankovnímu účtu samotný model by řešil jen zápis transakce do databáze a neřešil by aktualizaci zůstatku na účtu.
Rich Domain Model
- tento model už obsahuje i doménovou logiku,
- kromě toho, že řeší objektově-relační mapování, odhaluje i chování,
- samotný model zaručuje, že data jsou uvedena ve správném a konzistentním tvaru,
- splňuje také objektově-orientované principy - enkapsulace, zapouzdření,
- například při připočítání peněz k bankovnímu účtu by model zapsal transakci do databáze a zároveň by aktualizoval i zůstatek na účtu.
Po zhodnocení všech výhod a nevýhod tak vycházím z toho, že u jednoduchých aplikací možno použít i Anemic Domain Model. U komplikovanějších aplikací bych však upřednostnil model s komplikovanou logikou Rich Domain Model. Ideálním řešením může být nakonec i kombinovaný přístup, protože u některých věcí je výhodnější zvolit model Anemic a u jiných zase Rich Domain. V některých případech také může být zajímavým řešením nejprve zvolit používání Anemic a později ho zrefaktorovat na Rich-domain modul.
Už nyní se těšíme na další vzdělávací akce.
Zaujal vás tento článek a chtěli byste se o něčem informovat? Napište nám a rádi se vám ozveme zpět.
