Jak na Code Review?

Líbí se mi kontakt s tímto termínem. Nevím proč, ale dlouho jsem si představoval, že Code Review (CR) je jenom buzzword a aktivita, kterou pokud aplikujete tak již programujete “extrémně” a to už znamená, že jste jako lepší nebo co… LOL. V momentě kdy jsme se v týmu rozhodli, že tohle budeme praktikovat jsem si byl jistý, že je tohle blbost. Přišel mi požadavek na code review od kolegy a když koukám na ten kód tak jen jedu: aha jo chápu, tohle se mi nelíbí (tohle=nějaký pitomý zápis), chápu, nělíbí, chápu… Testy prochází? Žádné nejsou. No tak k tomu dopiš ještě testy a dobré. Releasujeme. Easy! Profesionální? Těžko!

Tak a teď pořádně?

To že postup výše je defacto zleva-doprava, zhora-dolů špatně nechme teď být. Z principu jde u code-review jen o to ujasnit si s někým jiným, že jsem porádně pochopil zadání a chci jej někomu prezentovat. Nejlépe hlavě osvícené, která nebude jenom pokyvovat, ale dokáže se mě zeptat na otázky typu: “Proč uvažujeme nad touhle věcí komplexně, když to jsou vlastně 2 oddělené problémy?”, “Nešlo by tohle vyřešit přes jednu iteraci?”, “Co kdyby uživatel nevplnil tohle?”, … Asi mi rozumíte co chci říct.

Metody extrémního programování jsou super užitečné obzvlášť kdy pracujete na nějasném zadání, které se může s iteracemi měnit do něčeho třeba i úplně jiného. Business požadavky většinou (pokud nemáte mezi zadavatelem a IT týmem kvalitní QA) řeší optimální případy a díky CR můžete v kódu odhalit nejenom code-smell, ale i implementační nedostaky způsobené právě špatným zadáním.

Co teda dělat?

Nejspíše si najdete optimální metodu odpovídající struktuře vaší společnosti, ale pokud s Code Review začínáte – zkuste si načrtnout na papír schéma vašeho problému a pár bodů, které si chcete objasnit s kolegou. Vysvětlete mu co řešíte za problém (i třeba pokud si myslíte, že on již jistě ví o co jde), projděte si vaše řešení a případné nedostatky dořešte již párovým programováním. Podtrhnul bych to úvodní schéma problému – pokud lidem začnete demonstrovat problém rovnou na kódu tak si sice lidi rozkývete a možná vám budou říkat, že souhlasí, ale pravděpodobně příjdete o všechny bonusy, které Code Review nabízí.

Jaké máte s Code Review zkušenosti vy?

Servisní třídy

Měl jsem možnost vidět implementaci servisních tříd (servisa) z několika různých úhlů pohledu, v několika firmách. Obecně všechny tyto implementace se drží obecného principu – oddělit aplikační logiku od té doménové. Tak to má být (?). Pojďme si tento pojem popsat v souvislosti s DDD (Domain Driven Design).

Rozdělení servisních tříd

Důvod implementace servisních tříd popisuje Eric Evans ve své knize “Domain-Driven Design: Tackling Complexity in the Heart of Software“, tedy

Pokud specifický proces v doménové logice není přirozenou zodpovědností Entity nebo Value-Objectu, pridejte tuto operaci do doménoveho modelu jako samostatné rozhraní deklarované jako služba. Definujte rozhraní v pojmech jazyka modelu a ujistěte se, že jména jeho operací jsou součástí “obecně srozumizelného jazyka” (Ubiquitous Language). Vytvářejte servisy jako nestavové.

Jak jistě někomu již došlo, tak předpoklad z úvodu článku v tomto případě neplatí – servisní třídy jsou součastí implementace doménové logiky (to co se často označuje jako servisa je již konkretní implementace – tedy třída nikoliv rozhraní).
Entity a value-objekty si jistě zaslouží svůj zvláštní článek (na ten se již můžete těšit).

V pojmech DDD se obvykle bavíme o 3 typech servisních tříd

  • Aplikační – Operují nad skalárními typy a transformují je v typy doménové. Skalárním typem rozuměj typ kterému nerozumí doménový model (typicky třeba http request).
  • Doménové – Operují naopak jenom nad typy, které jsou součástí doménového modelu.
  • Strukturální – Jde o operace které jsou mimo dosah doménové logiky. Jde o operace splnují požadavky externích služeb – tedy například odesilání emailů, logování atd.

Aplikační servísní třídy

Doménové servisní třídy

Strukturální servisní třídy

Tento článek je publikován jako nekompletní, na jeho dokončení se již pracuje.