V mém předchozím článku o volbě technologií do týmu jsme si na konkrétním příkladu ukázali, jak velký dopad může mít špatná volba technologie na tým a jeho fungování. Ale i rozhodnutí nepoužít nějakou technologii, ať už aktivní, či pasivní, může mít značný dopad na celý projekt a tým. A právě o tom je tento článek.
Tým, který začal vyvíjet jeden z našich středně velkých zakázkových projektů, byl sestaven z členů, z nichž všichni měli zkušenost s Nette a menšími projekty. U takových projektů si pro přístup k databázi vždy vystačili s jednoduchými knihovnami typu DBAL (DataBase Abstraction Layer), které jsou typicky jen tenkou vrstvou nad spojením k databázi, nad tabulkami a případně nad řádky v jednotlivých tabulkách.
Snadné neznamená správné
Bylo tedy přirozené, v rychlém tempu projektu, prostě použít to, co všichni nejlépe znali. Krátce sice zazněla myšlenka, zda nepoužít nějakou další abstrakci v podobě knihovny typu ORM (Object Relationship Mapping), avšak hlasy vzápětí umlkly, protože nikomu se nechtělo získávat znalost nové knihovny v boji.
Bolestivé zkušenosti
Tato lenost nás dovedla k řadě nabytých zkušeností v podobě pojmenovaných problémů:
- Nejasná struktura načtených dat. Přišel mi objekt, nebo pole? Je indexované, nebo má klíče? Je tam sloupec, který potřebuji? Bude tam ten sloupec ve všech kontextech volání této metody?
- Chybějící informace o vztazích. Z jednoho záznamu typicky nejde jednoduše/vhodně traverzovat na jiný, data je potřeba načítat explicitně, čímž se prodlužuje kód. Stejně tak při ukládání je potřeba celá data rozložit a správně uložit a v databázi pospojovat, což opět prodlužuje kód a vytváří příležitost pro množství chyb.
- Vlastní serializace a deserializace. U některých knihoven vznikají problémy při používání vlastních typů v databázi, např. v případě číselníku, geografických dat a podobně. Nehledě na to, že tyto serializace a deserializace mají tendenci dřív nebo později někde selhat z důvodu lidské chyby či opomenutí.
- Nejistá míra a místa extenze. Některé knihovny jsou natolik malé, že jisté úkony s nimi uděláte jen v případě, že si je ručně upravíte. Někdy nebudete mít úplnou nadvládu nad dotazy, jinde nad vlastními typy a dotazovými funkcemi. Jednou bude úprava zde, podruhé zase někde jinde – nepřehlednost a nepředvídatelnost udělají v kódu projektu pěkný nepořádek.
- Nejasný tok dat. Typická neexistence jedné instance dat při vyřizování požadavku může lehce způsobit nekonzistence. Stačí, když si něco někde načte nějaká stejná data vícekrát.
- Neefektivita. Pokud načítání provádíte v místě volání (šabloně, presenteru) svádí to k načítání dat na řadě míst, což vede k poměrně obtížně optimalizovatelné aplikaci, která opakuje stejné či podobné dotazy.
Spoustu chyb vyplývajících z těchto problémů jsme pojmenovali na řadě retrospektiv, při řadě code reviews a testů, přesto však pár z nich proklouzlo až na produkční prostředí. Společným jmenovatelem těchto problémů (či „symptomů“, chcete-li) je nedostatek architektury.
.jpg)
Takže kde je problém?
Problémem není nepoužití ORM, ale jednoduché používání DBAL bez vybudování jakékoliv další abstrakce, která by adresovala zmiňované problémy – a asi nebude moc velké překvapení, že právě tyto problémy typicky adresují knihovny typu ORM spolu s použitím některých dalších návrhových vzorů. Po pojmenování těchto problémů tak projekt stál před rozhodnutím, zda si napsat vlastní ORM podporu, nebo do něj nějakou ORM knihovnu implementovat. Vybrali jsme si tu druhou variantu, konkrétně v podobě Doctrine ORM – znovuobjevených kol už bylo dost.
Jak nás to poučilo?
Co si z toho odnést? Použití knihoven typu DBAL je příjemné, když je projekt malý, data jednoduchá, datové toky jednosměrné a velmi omezené. Jakmile ale projekt začne růst, správně navržená a rozšiřitelná architektura je nutná a použití ORM knihovny k tomu navádí. Poslední slovo ale stejně bude mít schopnost vašeho týmu z dobrých věcí postavit skvělou architekturu vhodnou pro váš projekt.
Sdílet článek