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ší Most Voted
Inline Feedbacks
Zobrazit všechny komentáře
Jan

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

Hermes místo OpenClaw?

AI
Komentáře: 0
Většina AI agentů v roce 2026 vám nabízí pohodlí výměnou za kontrolu — běží na cizí infrastruktuře, ukládají vaše data neznámo kam a fungují jen tak, jak je jejich tvůrci navrhli. Hermes od Nous Research jde opačným směrem: je open-source, nainstalujete si ho na vlastní server za pár dolarů měsíčně, připojíte k libovolnému LLM a necháte ho, aby si sám psal vlastní schopnosti podle toho, co od něj potřebujete. Výsledek? Agent, který skutečně patří vám a po pár týdnech používání rozumí vašemu setupu lépe než kterýkoli komerční asistent. Podívejme se, co Hermes umí, jak ho rozjet a pro koho dává smysl.

Robots.txt nestačí. AI crawleři mění, jak weby chrání obsah

Robots.txt zůstává základní signál pro slušné crawlery, ale už neumí popsat hlavní problém: stejný veřejný obsah může sloužit klasickému vyhledávání, AI odpovědím, tréninku modelů i načtení na pokyn uživatele. Provozovatel webu proto musí oddělit účel přístupu, ověřovat identitu botů, měřit dopad na infrastrukturu a u hodnotného obsahu řešit i vynucení pravidel mimo samotný robots.txt.

Jak funguje WordPress Cron a proč občas selhává

„Cron mi nějak neběhá." Klasická věta, která ve WordPress světě může znamenat cokoli od špatně nastavené WP_SITEURL, přes loopback zablokovaný Cloudflarem, až po fatal error v callbacku, který nechal viset transient doing_cron. WP-Cron totiž není skutečný scheduler — je to pseudo-cron závislý na návštěvnosti webu a HTTP loopbacku, se všemi pastmi, které si dokážete představit. Tenhle článek je hloubkový průchod jeho vnitřnostmi: co se reálně děje při spawn_cron(), kde vznikají race conditions, proč selhává a čím ho v produkci nahradit.