čtvrtek 12. července 2007

Konvenční lži

Čas od času narazím na rádoby pravidla týkající se vývoje a vývojářů. Tyhle pravidla osobně označuji termínem konvenční lež a v tomto článku se na tři z nich podívám.

Programátor po třicítce je neúspěšný programátor

Nevím kdo to vymyslel každopádně se setkávám s názorem, že pokud dělá člověk vývojáře po třicítce, tak s ním není něco v pořádku. Údajně to naznačuje, že je neúspěšný, protože se nedokázal posunout na vyšší pozici. Dokonce mám kolegu, který s oblibou říká Dal jsem si závazek, že ve třiceti nebudu programátorem. Můj názor je ten, že člověk by měl zastávat takovou pozici, která ho naplňuje a pak je úplně jedno kolik mu je let.

Dokonce bych řekl, že většina programátorů zraje jako dobré víno. To neznamená sice, že platí starší vždy lepší, ale zkušenost dělá hodně. Jedna z námitek na vrub starších programátorů je ta, že nedokáží být dostatečně inovativní. To je další nesmysl, protože místo věku hraje roli charakter vývojáře. Narážky na věk a úspěšnost bych zakončil paralelou ze sportu. Hokejovému brankáři Dominiku Haškovi je 42 let a přesto patří mezi absolutní špičku kanadsko-americké NHL a nikdo se neopovažuje zpochybnit jeho schopnosti.

Architekt by neměl kódovat

Kódovat či nekódovat? Architekt by údajně neměl kódovat a měl by si držet odstup a starat se pouze o architekturu aplikace. Každý architekt, který přestane absolutně kódovat podle mého názoru ztrácí smysl pro reálné použití daných technologií a většina jeho odhadů a rozhodnutí je tímto negativně ovlivněna. Jestli je něco pohroma pro každý projekt, pak je to architekt teoretik.

Pokud mám být jako architekt za systém či jeho část být zodpovědný tak musím nejen znát jeho architekturu, ale musím být schopen obhájit i praktické řešení, za které nesu odpovědnost. Někdo zastává názor, že architekti by měli dělat code review a tím si držet kontakt s realitou. Dle mého názoru se pro code review lépe hodí nástroje pro statickou analýzu kódu.

Architekt by se měl podílet nejen například na návrhu API, ale i na jeho implementaci a na tom, že celé API drží linii, která byla navržena. Architekt, který něco navrhne a tím to pro něj končí a nebo dokonce není schopen prosadit/obhájit to co navrhnul, je špatný architekt.

Nepředvídejme budoucnost, protože nakonec bude úplně jiná

To jsem slyšel ve spojení s návrhem API. Nedávno jsme zde diskutovali objekt, pro který jsme vytvořili rozhraní kopírující jeho public metody. Já tento vzor používám často a rád pro API, která používá klient z jiné vrstvy aplikace. Troufám si tvrdit, že pokud tvoříme API tak vždy předvídáme budoucnost a proto je více než užitečné nezabouchnout si dveře tím, že budu někoho nutit používat konkrétní třídu.

V tomto smyslu je předvídání budoucnosti zbytečné u věcí, které mají jednorázové použití a nebo které lze velice jednoduše refaktorovat. Jenže kolikrát se z jednorázových řešení stanou řešení nejednorázová? Řekl bych,že přirozenou evolucí skoro u většiny. Potom je ve větších projektech tento refaktor holým neštěstím. Ano budoucnost může být jiná, ale většinou není tak diametrálně odlišná, abychom ji nemohli alespoň částečně predikovat a tím si v budoucnu ušetřit plno práce.