Přejít k navigační liště

Zdroják » Různé » Vývojáři, nač ten spěch?

Vývojáři, nač ten spěch?

Články Různé

Nedávno jsem na Lifehackeru četl článek s názvem Co bych byl rád věděl, když jsem začínal jako softwarový inženýr, přejatý z původní Quora odpovědi od Michaela O. Churche. Nedokážu ho vyhnat z hlavy. Asi mě trochu provokuje, že ačkoli s ním v podstatě souhlasím, mám za svých 20 let zkušeností s vývojem docela jiné závěry.

V anglickém originále zveřejněno na blog.salsitasoft.com.

Michael doporučuje mladým programatorům podávat spíše průměrné výkony, ale zároveň dává spoustu skvělých rad, jak se proplést firemní politikou a vyjít z ní jako vítěz. Nebudu naivní – schopnost „ukecávat“ je samozřejmě velmi prospěšná, ale žijeme ve věku Alfa Ajťáka a dobří vývojáři jsou nedostatkovým zbožím. Pokud v práci neoceňují vaše mystické schopnosti s kódem, proč se trápit s řiťolezectvím? Prostě změňte práci. Především, jen jedna z Michaelových čtrnácti pouček se přímo týká programování – „Rozpoznejte hlavní technologické trendy na trhu“. Zbytek jsou dobré, ale docela obecné rady, co se hodí do každého zaměstnání. Už název článku („… jako softwarový inženýr“) ale napovídá, že by měl být konkrétnější k profesi vývojáře; alespoň tak bych k otázce přistoupil já.

V pubertálním rozpuku jsem se cítil jako opravdu skvělý programátor. Na posezení jsem dokázal napsat pár set řádků v C nebo Pascalu a úspěšně je zkompilovat na první pokus. Spojoval jsem si dokonalost softwarového inženýrství se schopností řešit složité technické problémy a s přirozeným, skoro instinktivním smyslem, jak převést řešení do kódu.

Ještě více než to jsem si ho ale spojoval s rychlostí. Na koleji jsem byl pyšný, že se dokážu týdny flákat po hospodách a hrát fotbálek, a pak všechno (zběsile) naprogramovat o víkendu v noci s hektolitrem kávy. To dokáže jen skvělý programátor, ne?

Až na vysoké se v mém sebevědomí začaly objevovat trhliny. Dostal jsem práci v jedné malé překladatelské společnosti na předměstí Paříže jako jediný vývojář ambiciózního systému na správu terminologií. Ačkoli jsem stvořil bezpochyby působivý prototyp, nikdy se nedostal do produkce. Teď už vím, že to byl na bohémský styl vývoje třiadvacetiletého Matta až příliš složitý projekt. Ta zpropadená „General Protection Fault“ ve Windows 3.1 se objevovala tak často, že mě tehdejší šéf/CEO začal sarkasticky oslovovat: „Salut, mon Général!“

Dalších dvacet let mě naučilo spoustu o důležitosti dobré softwarové architektury, neúprosného testování a výhodách dokumentace. Pravdou ale je, že ta nejzajímavější lekce mi došla až nedávno; po dvou dekádách více i méně technicky úšpěšných projektů, které jsem ale nikdy nevnímal jako nějaké zářící hvězdy na nebi softwarového inženýrství.

Mnohokrát jsme se s kolegy shodli, že ten a ten projekt nemůže zabrat více než tři měsíce. Jak se ale blížíte k prvnímu roku, tak se i původně velkorysé odhady zdají naivní, když za sebou vidíte všechna ta zákoutí a implementační detaily. Odhady bývají beznadějně nerealistické a slepá snaha je plnit věci často naopak komplikuje.

Pokud máte nápad na použitelný produkt, který nachází poptávku, a postavíte ho na kvalitních základech, tak máte velkou šanci, že bude relevantní ještě v době vydání. Trh se nehýbe tak rychle, aby se závodilo jen o datum uvedení na trh – z mé zkušenosti vítězí převážně kvalita provedení a spolehlivost než ideální okno pro marketing, které v praxi často končí s bugy a chutí zapomenout.

Přesto velká většina vývojářů neztrácí čas s testováním, designovou dokumentací a code reviews (mé oblíbené téma!). Existuje totiž všeobecný názor, že práce vývojáře je o „psaní kódu“ a ostatní věci jen snižují produktivitu.

Neříkám, že bychom měli psát detailní specifikaci ještě před tím, než sáhneme na kód. Věřím v agile a zbouchat během chvilky něco funkčního je skvělý start většiny projektů. Musíme si ale také najít čas důkladně refaktorovat a vylepšovat původní řešení, správně testovat a dokumentovat náš kód za běhu. Ta neurčitá budoucnost, „kdy bude více času“, bývá už pozdě. Musíme si uvědomit, že naše práce není o rychlosti psaní, ale tvorbě kvalitního, stabilního, výkonného a udržovatelného softwaru.

Tak tohle bych byl rád věděl, když jsem začínal jako softwarový inženýr – jak (sakra) trochu zpomalit.

Salsita Software

Salsita Software je softwarová společnost, která se specializuje na vývoj komplexních moderních webových a mobilních aplikací. Sponzorujeme JavaScripting.com, komunitní portál, který pomáhá vývojářům hledat knihovny a frameworky pro JavaScript.

Překlad: Filip Naumovič

Komentáře

Subscribe
Upozornit na
guest
1 Komentář
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Jan

Souhlasim.
Programatorske peklo je dlouhodobe udrzovat nejakou slataninu, v horsim pripade jeste nedokumentovanou.
Code review taky neni uplne bezna zalezitost.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.