Dokumentovanje odluka

Dokumentacija projekta je vragolasta drugarica: kada nam ne treba, ima je previše; kada nam zatreba, ima je premalo. O dokumentaciji je puno toga već dokumentovano (eto šale): od toga kako se komentariše kod, do postojanja jezika kojim se opisuju softverski sistem.

U svemu tome postoji vrsta dokumentacije koja je važna, a nisam imao prilike da vidim da se praktikuje. Reč je o dokumentovanju odluka u vezi arhitekture sistema. Dakle, ne same aktuelne arhitekture, već odluka kojima se do nje došlo.

Odluke su deo projekta

Na svakom projektu se donosi nemali broj - definitivnih - odluka. Koje biblioteke koristiti, kako su uvezane komponente sistema, kako one komuniciraju, gde su granice modula, kakav je tok podataka… Odluke se donose i za rešavanje tehnoloških izazova koji se javljaju u toku razvoja.

Opis odluke je, pojednostavljeno, sažeto objašnjenje zašto je nešto urađeno na jedan, a ne na neki drugi način. Jedna takva odluka bi mogla da sadrži sledeće:

Odbačena - odnosno druga razmatrana rešenja je neophodan deo dokumentovanja odluke, možda i najvažniji. Bitno je da sagledamo zašto nam neko drugo rešenje u tom trenutku nije odgovaralo. Pri tome je sasvim u redu da razlog za odbacivanje bude subjektivan; kakav kog da je, bitno je da se zabeleži svaki.

Beleženjem odluka u vezi arhitekture pomaže da sazrevamo: čini arhitekturu uporedivom u okolnostima u kojima odluka važi. Matematički rečeno, odluka je funkcija koja je prevela arhitekturu iz jednog oblika u drugi. Može li se arhitektura zapravo predstaviti kao… formula?

Skalirajte sada ovu zamisao. Moćno, zar ne?

🧧
Nisam definisan svojim stavovima. Stavove usvajamo, menjamo, nadograđujemo, ali oni ne čine nas same. Manje je važno da li se slažemo,
koliko da se razumemo.
> ČASTI KAFU <