Myslím, že člověka k programování přitahuje primárně vysoká tvůrčí kreativita v tomto oboru. Vývojář má možnost jako meta-tvůrce vytvářet nový virtuální svět (jakýsi svůj „Matrix“) podle jeho takřka „božské“ libovůle. Nejhezčí na tom je, že tento svět bude skutečně takovým, jaký jej stvořitel programátor vytvoří.
Časem jsem vypozoroval ještě jedno velké plus: Pokud pominu sociopatické výjimky, tak 99% vývojářů a programátorů chce odevzdávat kvalitní práci na vysoké profesionální úrovni (i když někdy nemohou) a jsou proto nadšeni pro svou profesi. Toto nadšení naplňuje práci v týmu zvláštním druhem energie (pokud není v týmu ubíjena) a bývá i dobrým hnacím motorem ve vývoji. Přece jen, pokud jste dosazeni do role meta-tvůrce systému (a jste vcelku normální), tak se snažíte, aby vámi vytvořená díla byla pokud možno dokonalá už jen „pro ten pocit“ (a nejenom pro peníze). Mimochodem z toho plyne, že většina programátorů a vývojářů jsou tak trochu ješitní v tom dobrém slova smyslu a jsou pyšní na svou práci. Například mám ověřeno, že pokud byl analytik anebo programátor donucen své výsledky práce prezentovat, tak se na ni připravil velice dobře z velmi jednoduchého důvodu: Je pro něj větší morální ztrátou špatná prezentace před kolegy než potichu přijít o prémie. Například SCRUM se svou filosofií schůzek zavádí nejenom zpětnou vazbu pro další kroky vývoje a postupů, ale přináší do práce i tento emotivní náboj spolupráce s prezentací výsledků (např. daily scrum, sprint review, sprint retrospective aj.)
Jenže střet s realitou bývá někdy hodně drsný.
Všichni vývojáři moc dobře znají tyto věty: „Včera bylo pozdě.“ „Není čas si s tím hrát.“ „Vím, že ten kód není dokonalý, ale co se dá dělat, odevzdejte jej tak, jak je…“ a jiné podobné věty.
Programátor chce sice odevzdávat kvalitní kód, ale je okolím tlačen do metody psaní kódu zvané taky jako Quick-and-Dirty-Programming. Vývojář prostě dostane pokyn: programujte rychle a nevadí až tak moc, že špinavě, hlavně že to jakž takž chodí. Díky těmto okolnostem je vytvářen tlak na sice rychlou tvorbu kódu, ale ten je nekvalitní, chybový, špatně otestovaný, netransparentní, nečitelný, neflexibilní…
Zde začíná zvláštní dilema a „neřešitelný rozpor“: Na jedné straně bychom už z principu rádi odevzdávali kvalitní a čistý kód, na straně druhé jsou programátoři tlačeni do techniky psaní kódu metodou Quick-and-Dirty-Programming.
Jak tento častý rozpor řešit a jak minimalizovat následky případných ústupků? Právě o tom bude pojednávat tento mini-seriál.
Mimochodem této problematice se také věnuje jedna z praktických částí 3 denního školení Čistý kód v OOP & Design Patterns, (in-house i prezenční), detailněji viz zde
Jak u vás?
Setkali jste se někdy s tlakem na tvorbu kódu metodou Quick-and-Dirty-Programming?
Máte svoje zkušenosti s tímto přístupem?
Napište svoje postřehy a myšlenky do diskuse níže!
Pokračování následuje
Napsat komentář