čtvrtek 28. května 2009

Popis architektury


Nedávno jsem se dostal k jednomu projektu, na němž tým vývojářů s menšími obměnami pracuje přes tři roky.
A už dlouho jsem se necítil tak hloupě, jako právě u tohoto projektu.

Proč?

Protože, abych pochopil celkovou architekturu, musel jsem studovat zdrojový kód. Na začátku jsem dostal krátký briefing, od mimořádně sdílného programátora, jehož nejdelší věta se skládala z pěti slov.
Když jsem se zeptal, zda mají k dispozici nějakou dokumentaci, pomocí níž bych se s celým projektem seznámil, začali se hýkavě smát.

Dovedete si asi představit, že to celé vedlo k naprosté frustraci a vyčerpání. Hodiny strávené studiem kódu, jež měnil styly a sémantiku téměř s každou třídou, byly naprosto ubíjející. Nicméně se mi podařilo do kódu proniknout a podařilo se mi svůj úkol splnit.
Po dokončení práce jsem přešel na jiný projekt, a musím přiznat, velmi rád.

Nedokumentovat kód je obecně špatná věc. To víme všichni. Jenže zároveň dokumentovat kód je strašně otravná věc a pro vývojáře naprosto nedůstojná a pokud to jen trochu jde, nedělá se to. Ne nadarmo se říká, že nejlepší programátor je programátor líný. A chtěli byste po takovém člověku, aby dokumentoval kód. Našel v sobě zbytečky vyjadřovacích schopností a popsal význam, chování a příklady použití třídy, kterou navrhl za pět minut, ale dokumentací by měl strávit půl hodiny.
Nemyslitelné.

Na jednu stranu je to dobře. Tedy, částečně dobře. Umění je rozhodnout, kdy kód dokumentovat a do jaké míry a kdy ne. Nepředpokládám, že u malé utility aplikace byste vytvářeli dokumentaci na dvacet stran.

U složitějších aplikací je potřeba mít alespoň popsanou rámcovou architekturu a její důležité části, například ty, u kterých se při implementaci vyskytly problémy a bylo je potřeba řešit konkrétním způsobem.

U vysloveně složitých aplikací je potřeba dokumentovat a to velmi důsledně. Vy, kteří tak nečiníte, mnoho štěstí, řítíte se do pekel.

Věřte mi, sám jsem tam už několikrát byl.