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

Odebírat
Upozornit na
guest
1 Komentář
Nejstarší
Nejnovější Nejvíce hlasů
Jan

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

Zahoďte knihovny: dropdowny, tooltipy a přechody stránek jen s HTML a CSS

Rozbalovací menu, tooltip, modální okno a plynulý přechod mezi stránkami. Ještě nedávno čtyři důvody, proč do projektu přidat několik knihoven a desítky kilobajtů JavaScriptu. V roce 2026 už to všechno zvládne prohlížeč sám. Ukážeme si, jak na to s Popover API, CSS anchor positioningem a View Transitions, a také kde mají své limity.

Rok po Shai-Hulud: co se změnilo na npm a co musíte udělat do ledna

Před rokem začal registrem npm procházet samošířící červ Shai-Hulud. Od té doby se útoky na dodavatelský řetězec JavaScriptu staly pravidelnou záležitostí a npm postupně přepisuje pravidla publikování. Projdeme, co se za ten rok stalo, jak dnes bezpečně publikovat balíček, co musíte stihnout do ledna 2027 a jak se bránit jako uživatel balíčků.

Vercel zrychlil směrování v CDN. Překvapivě pomohly menší bloky

Vercel zrychlil směrování v CDN tím, že začal načítat víc dat najednou. U velkých webů mu po každém nasazení scházely v cache údaje o mnoha jednotlivých cestách, takže je musel opakovaně dohledávat. U nových bloků metadat Vercel naměřil o 91 % kratší dobu tohoto hledání v 99. percentilu. Cesta k výsledku ale vedla přes nečekané zjištění: příliš velký blok se při vyřizování požadavků nevyplatil.