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
Prosperující SW firma hledá analytiky a JAVA programátory v okolí Hradce Králové
V případě zájmu pište na e-mail objects@object.cz
Snad by měla být závěrečná otázka “Kdo se nesetkal s Quick and dirty? :)
Můj zážitek: Jeden systém se měl nahrazovat jiným Tedy v dosluhujícím se vše nařídilo dělat QaD. Jelo se tak rok. A nový systém se pak nepodařilo nasadit a pokračovalo se ve starém. Dá se to, ale stavět na tom dále je hrůza, postupně se moduly musely čistit, nikdo to nechtěl platit… těžká situace :)
U nás v práci jsem 12 let. Dělali jsme dobrý kód a dobré produkty, i jako vývojáři jsme byli s výsledky práce spokojení. Tak nějak sami jsme zaváděli vzory a vylepšovali své metody, čistě z principu, aby to šlo dobře udržovat. Někdy v průběhu času se ovšem zlomilo. Vedení začalo nabírat projekty, které se prostě nedaly stihnout s danými kapacitami a tak se to před pár lety začalo flákat. A od té doby se nenápadně firma začala sunout ke dnu. Postupná ztráta motivace. Postupně se chaotický vývoj stal standardem. A hlavně jsme před sebou pořád valili to, co se v rychlost udělalo špatně. Pořád jsme chtěli čas na systémovou práci a on pořád nebyl. Až do vyvrcholilo tím, že dobré programátory to prostě přestalo bavit a hledají si práci jinde.
Zdravím, záslužná práce. Ve světě se těmito jevy občas někdo zaobírá. U nás mnoho lidí neznám. Takže God bless Ilja! Dokonce se v článku objevují pojmy, které jsou v IT zapovězeny, tabu a autoři jsou podezíráni z náboženských praktik ;-)
A jak to řeší ve světě? Dejte si do GOOGLE tři slovíčla: iso bpmn gap
A hned na první dobrou si stačí přečíst jen anotaci…
Asi je to telepatie, ale zrovna se chci domluvit se serverem ZDROJAK , jestli by se o těchto architektonických jevech nedal u nich provozovat nějaký blog nebo miniblog.
Vloni jsem na JOBSDEV učinil verifikaci, že tohle zajímá v IT asi tak 3 procenta lidí, u nás v Česku asi ještě méně. Salman Khan to vidí v roce 2050 – že se bude v práci seberealizovat 60 procent lidí. Teď to jsou ta 3 procenta. Pro zbytek je to otroctví, už ne fyzické, ale duševní. A teď ještě TI ROBOTI! V IT se jich bojí jako čert kříže. Programujeme jako před 25 lety. Ještě nikdo mi neodpověděl na otázku, v čem to děláme jinak. Co už tehdy nebylo. A ptal jsem se nějakých lidí… To není staromilství, to je fakt, že všude kolem to frčí, jen IT je konzervativní a hlavně vede v prokrastrinaci. To není ze mne, já s tím plně souhlasím.
A ještě k tomu Salmanovi – Václav Havel předdběhl dobu asi o 3 generace. I on přece mluvil o seberealizaci. Nebo jste měl někdo hlad?
Takže tah na branku, týmová spolupráce (ala Jan Muhlfeit) a onen “gap” už je menší problém.
Samozřejmě to není všechno, ale je to to podstatné, ty detaily bych chtěl rozproudit na tom miniblogu nebo na JOBSDEV 2018 v dubnu – také to tam zkouším ziniciovat…