Co je s tím kódem špatně?

“Hlavní je, aby to fungovalo”. Oblíbená mantra project managerů a začínajících programátorů, která u dlouhodobých projektů končí velkou tragédií. Zpravidla hned po tom, co se tahle mantra osvědčí, dochází k obratu a všechno se začne hroutit. Každý programátor i project manager se s tím někdy setkal: Přidávání featur jde hezky od ruky, pak to začne drhnout a nakonec přidání nový featury způsobí zhroucení hvězdy na druhém konci vesmíru.

Hlavní hodnota kódu, který píšeme, není to, že to funguje. Ta hlavní hodnota je v tom, že tu funkčnost dokážeme rozšiřovat, případně měnit podle nových požadavků. Toho je relativně lehký docílit u malých projektů, kde je málo změn. U rapidně se rozvíjejících produktů s hromadou featur je ale třeba věnovat patřičnou péči jak návrhu aplikace, tak způsobu programování, jinak se začne neúměrně zvyšovat komplexita a provázanost. To pak způsobuje výše zmíněné hroucení hvězd, ale i probdělé noci, strach z deployů, naštvané managery, naštvané zákazníky, naštvané přítelkyně, promarněné příležitosti, slzy v očích a dokonce i smrt.

Proč se to teda děje?

Každejch 5 let se zdvojnásobí počet programáorů, takže je to zákonitě obor, ve kterym panuje podvzdělanost. Přibývá technologií, knihoven a kdo se v tom má vyznat, když polovina lidí jsou „nováčci“?

Programátorů je pořád málo a jsou drahý takže je na ně přirozeně vyvíjenej tlak, aby všechno bylo co nejdřív.

Programátoři dost často neumí říct ne, proto ve tlaku často volí krátkodobě výhodnou, ale dlouhodobě destruktivní cestu pomocí hacků a zkratek, které už nikdy neodstraní. Je to však profesně stejný přestupek, jako kdyby se doktor podvolil tomu, že „je třeba operovat rychle a tak nebudu ztrácet čas mytím rukou“.

Programátoři se špatně vzdělávají. Tohle je dost individuální, ale často programátoři nemaj čas/energii na to se dostatečně vzdělávat, nebo se soustředí jen na konkrétní “cool” technologie, které v návrhu aplikace hrají roli implementačního detailu (což vůbec neznamená, že to není důležitý!), ale podceňují důležitost “konzervativních” metod a pravidel, jako je Test Driven Development, SOLID principles a podobně. To hodně vnímám u PHP komunity ve který se pohybju.

Můžou za to ale jenom programátoři? Nejenom!

Project manageři často nevěnují pečlivou pozornost zadání a plné komunikaci byznys domény, kterou mají programátoři řešit. Mají pocit, že stačí hrubě načrtnout představu a programátoři se „už o ty technické detaily postarají“. Často to však nejsou jen technické problémy, ale fundamentální byznysové principy, které je rozhodně potřeba pojmenovat a společně vyřešit.

A řešení?

Podle mě jsou to jak nástroje pro zlepšení komunikace mezi programátory a zadavateli (ano, myslím třeba různé agile nástroje a techniky), tak techniky extreme programmingu (agile je jeho součástí). Propagace osobní zodpovědnosti, profesionality, vzdělání a odvahy dělat věci jinak, líp. Co nejlíp, jak je to v našich silách. Dělit se o zkušenosti a podporovat v tom ostatní. To s sebou krátkodobě přináší rizika, obětování a nepohodlí, ale dlouhodobě je to jenom úžasný, to vám řekne každý, kdo to aktivně dělá! 🙂

A proto sem tady zapnul tenhle blog, abych se podělil a ideálně rozpoutal diskuzi o maximu z toho, co jsem se naučil, na co jsem přišel, o čem jsem se dozvěděl a o čem si myslím, že by se mělo víc mluvit.

Příspěvek byl publikován v rubrice Nezařazené a jeho autorem je tomcizek. Můžete si jeho odkaz uložit mezi své oblíbené záložky nebo ho sdílet s přáteli.