Seriál Quick-and-Dirty-Programming Část 7: Proč je v SW firmách tak rozšířen zlozvyk tvořit paskvilný SW „Dirty Code“ ?

Nedávno jsem obdržel tento mail (publikuji bez úprav):

Vazeny pan Kraval,

cital som Vas serial Quick-and-Dirty-Programming a som rad ze o tom niekto pise.

Som v situacii, kde model projektu neexistuje a vsetko sa zistuje reverznym inzinieringom a samozrejme opatovne vzdy, ked sa v danej casti aplikacie robia zmeny. Frustrujuca situacia, hlavne ked sa jedna o dlhodoby projekt, ktory sa postupne vyvija.

Myslim, ze problem je v tom, ze vacsinou ludia nemaju skusenosti s inym ako quick and dirty vyvojom. Profesia vyvojara je stale “profesiou z garaze”. Na vykonavanie tejto profesia by to chcelo znalostne skusky, napr. ako v medicine :)

prajem Vam krasny den,
K. F.

Shodou okolností jsem v některých posledních zakázkách narazil na podobný problém a to hned v několika firmách: Vytvářel se v nich kód jako typický paskvil, tj.

  • neexistoval žádný analytický model (resp. odevzdávaly se dokumenty nazývané jako „analýza“, ale byly úplně mimo potřeby návrhu SW),
  • neprovádělo se žádné posouzení čistoty návrhu,
  • nezkoumala se správnost vrstev atd.
  • a k tomu samozřejmě vzájemná spolupráce programátorů byla minimální, tedy spíše nulová…

Zajímavé je, že v těchto firmách jsem narazil na určitou formu odporu vůči metodám, které by měly vést k lepšímu výsledku, a to i přesto, že mnozí opravdu zainteresovaní vývojáři volali po změnách, protože tento stav byl pro ně neúnosný.

Celou situaci dobře vyjadřuje tento sice starý, ale velmi výstižný kreslený vtip:

Poslední odstavec mailu týkající se znalostí vývojářů spolu se zkušenostmi z těchto firem mne přivedl k otázce:

Jaké jsou vlastně překážky ve firmách, které brání tomu, aby se firma vyvarovala tvorbě „Dirty Code“?

Myslím, že je to velmi dobrý námět k diskusi. Osobně jsem narazil na tyto základní překážky pro zavedení správných postupů ve firmě:

  • Nechuť vedení k jakýmkoliv změnám. Většinou managment odborně hodně vzdálený od postupů tvorby SW vůbec nechápe, v jakých problémech se firma nachází a z toho důvodu se vedení jakýmkoliv změnám brání. Pokud by ale dotyční „výše postavení“ tušili, do jaké žumpy se tímto firma topí, asi by tak trochu zpanikařili (pokud se tedy vedení neřídí principem „po nás potopa“).

  • Touha po nezastupitelnosti některých vývojářů, zejména dlouholetých programátorů, kteří nechtějí nikoho pustit na svůj „píseček“. Vzpomínám si při této příležitosti na jednu charakteristickou situaci v jedné firmě: V rámci školení jsme dokončili jako ukázku jeden analytický model agendy, o které se před tím hovořilo „až s posvátnou úctou“. Cestou k vrátnici jsem ve výtahu ke kolegovi jen tak mimochodem prohodil: „Ona ta agenda není až tak složitá, jak se mi zdála na počátku…“ A dotyčný kolega mi na to odpověděl: „Víte, ony se u nás ty agendy tak trochu démonizují…“

  • Neznalost vývojářů. Protože nejsou žádné tlaky, není ani touha se v tomto směru vzdělávat. Zkratky jako SOLID, GOF, DRY apod. jsou víceméně španělskou vesnicí. Právě o tom píše kolega v mailu a myslím, že je to jen jedna z částí problému v celém kontextu.

Rád bych na toto téma zahájil diskusi.

Obracím se na čtenáře s těmito otázkami:

  • Není tu snad ještě něco, co jsem přehlédl?

  • Jaké máte vy zkušenosti s těmito situacemi?

  • Který z těchto vyjmenovaných bodů je asi nejhorší?

  • A hlavně: Jaké si myslíte, že to má řešení?

Budu se těšit na vaše příspěvky v diskusi pod článkem!



Categories

About the Author:

správce a majitel Serveru objektových technologíí http://www.objects.cz

2 Comments
  1. Jiří Matějček

    Děkuji za článek, jako úvod pro diskuzi dobrý.
    Momentálně náš tým spravuje rozsáhlý systém s dvacetiletou historií – cca 5000 db tabulek, mnoho procesů, aplikací, interfaců, automatických úloh. Jednu dobu byl “na odpis”, tedy QaD bylo nařízeno, ale pak se zase rozhodlo, že se bude používat dále. Systém je v dobré kondici, i když se setkáváme se vším, co k QaD patří: mrtvá data, mrtvé kódy, nepoužívané části aplikací, neúplná dokumentace, uzavření vývojáři.
    Co nás drží nad vodou: pamětníci, zdrojové kódy, komentovaný datový model a regresní testy.
    Jeden pamětník neví všechno, ale když se jich pár obejde, tak lze rekonstruovat, jak se systém zhruba chová. Pak vlézt do kódů a postupně si teorii ověřit. Máme tedy high level a low level. Střední vrstva chybí.
    Démonizace je zde opačná – zpočátku se zdá úprava snadná, ale postupně se objevují démoni :)
    Myšlenku na vytvoření celkové dokumentace a udržovat ji aktuální již považuji za utopii, není to prostě možné. Pár pokusů tu bylo (ve wordech nebo v EA). Je to natolik rozsáhlé a provázané, že byste tam stejně nenašli informaci, kterou právě potřebujete a aktualizovat dokumentace se nestíhala, vývoj byl vždy o míle napřed, a nebyl dostatek lidských sil na její udržování, a stejně tam byly chyby nebo bílá místa. přitom vedení je dokumentaci nakloněno, podporuje jí, ale v tom objemu se to nedá zvládnout.
    Jak se systém opravdu chová je přesně dáno ve zdrojovém kódu. Jsem vděčný za každý komentář, který pomáhá pochopit, co kód dělá. Toho jsem se chytil a momentálně pracuji na aktivitě, aby se kód dobře strukturoval, pojmenovával a komentoval. Když někdo porvede QaD, aspoň aby to tam napsal (a někteří to tam opravdu napsali, děkuji).
    A dávám tomu nový pohled: Nekomentovat svůj kód, ale kód kolegy, protože svému kódu vývojář perfektně rozumí a nepotřebuje ho moc komentovat. Ovšem, když to louská někdo po něm, některé konstrukce hned nepochopí. A právě zde by měl vyvolat potřebu komentáře.
    Tedy moje low level řešení je “komentovaný kód”, včetně “okomentuji kód, který jsem po někom rozlouskal”.
    Všichni analytici zde umí kód číst, to je předpokladem, jinak to nebude fungovat.
    Chápu, že to není řešení nejlepší, ale lepší jsme do praxe zatím nedokázali zavést.
    Myslím si, že velikost systému hraje zásadní roli při správě dokumentace.U menších systémů (do cca 500 tabulek) jsme vždy aktuální dokumentaci dokázali udržel (EA, wordy, excely), ale zvětšováním systému nestoupá závislost údržby dokumentace lineárně, ale násobně díky vazbám a množstvím jejich kombinací.

  2. Eduard Sovák

    Přestože pracuji ve velké IT firmě, musel jsem v posledních letech mnohokrát obhajovat potřebu analytického modelování. Problém je v tom, že pokud se analýza provádí rigidně a striktním vodopádem, pak rychlé potřeby byznysu skutečně nestíhá. Na druhou stranu nad dobře vedeným analytickým modelem se snadněji provádí dekompozice systému, takže model jeho jednotlivých části lze udržovat poměrně efektivně tak, aby nepřerostl přes hlavu. Jako problém zejména u mladších analytiků vnímám i to, že se detailně zaměřují především na změnovou dokumentaci. Kvalita modelu, který vyjadřuje celkový stav systému (a měl by motivovat k občas potřebnému refaktoringu), je často opomíjena. Určitě v tom hraje roli i fluktuace, která k udržení dlouhodobé kvality nemotivuje.

0 Pings & Trackbacks

Leave a Reply