Co vás reálné projekty naučí, co v tutoriálu nezažijete?

Když se člověk učí programovat, většina problémů má jednu příjemnou vlastnost: někdo je předem připravil tak, aby šly vyřešit.

Tutorial ví, co bude následovat. Zadání obsahuje potřebné informace. Databáze má strukturu, se kterou autor počítal. Když uděláme stejných deset kroků, měli bychom skončit přibližně na stejném místě jako člověk ve videu.

Takové prostředí je pro učení skvělé. Umožní pochopit nový framework, databázi, API nebo způsob práce bez toho, aby člověk zároveň řešil dvacet problémů okolo.

Jenže reálné projekty takhle nevypadají.

Klient nemusí přesně vědět, co potřebuje. Dokumentace může být neaktuální. Externí služba se začne chovat jinak, než slibuje její dokumentace. Po týdnu zjistíme, že technicky správná implementace neodpovídá tomu, jak lidé produkt skutečně používají. A někdy se změní samotné zadání ve chvíli, kdy je jeho první verze téměř hotová.

Právě proto mám pocit, že jsem se nejvíc neposunul ve chvíli, kdy jsem se naučil další technologii, ale když jsem začal pracovat na věcech, které musely skutečně fungovat pro někoho jiného než pro mě.

Najednou nestačilo vědět, jak napsat kód.

Bylo potřeba dostat nejasný problém do stavu, kdy z něj vznikne spolehlivý výsledek.

V reálném projektu vám nikdo nepřipraví problém tak, aby se dobře řešil

Cvičné zadání často začíná poměrně přesně: vytvořte aplikaci, která umožní uživateli registrovat se, přihlásit a spravovat seznam úkolů.

V praxi může zadání znít spíš:

„Potřebujeme, aby si naši zákazníci mohli spravovat účty.“

To je začátek konverzace, ne specifikace.

Co přesně znamená účet? Existuje více typů uživatelů? Může jeden člověk patřit do několika firem? Kdo ho zve? Co se stane, když odejde zaměstnanec? Jak funguje reset hesla? Má být povinné dvoufázové ověření? Které údaje může měnit sám a které pouze administrátor?

Každá odpověď může otevřít několik dalších otázek.

Tohle pro mě byla jedna z prvních důležitých lekcí z reálných projektů: vývoj nezačíná kódem, ale redukcí nejasnosti.

Člověk musí umět zjistit, co zákazník skutečně potřebuje, odlišit podstatné věci od detailů a upozornit na situace, které zadavatel nemusel vůbec předvídat.

Zároveň se nesmí dostat do opačného extrému a snažit se před prvním řádkem kódu specifikovat každou možnou situaci. Některé věci jednoduše zjistíme až během práce.

Dobrý vývojář proto podle mě není člověk, který potřebuje dokonale připravené zadání. Je to člověk, který dokáže s neúplným zadáním pracovat, aniž by zbytek doplnil náhodnými předpoklady.

Zdánlivě jednoduchá funkce skoro nikdy neexistuje sama

V tutorialu může být například upload obrázku jedna kapitola.

Vybereme soubor, odešleme ho na server, uložíme a zobrazíme.

V produkčním systému ale velmi rychle přijdou další otázky. Jak velký soubor může být? Jaké formáty podporujeme? Co uděláme s obrovskou fotografií z telefonu? Kdo může soubor otevřít? Co když upload selže uprostřed? Má se starý obrázek po změně smazat? Jak řešíme soubory, které už nejsou navázané na žádný záznam?

A tím se dostáváme k další věci, kterou cvičné projekty často schovají: jednotlivé části softwaru nejsou izolované.

Změna databázového modelu se projeví v API. Změna API ovlivní frontend. Nový stav objednávky může změnit e-maily, analytiku, administraci i účetní integraci. Úprava oprávnění může mít dopad na prakticky celý systém.

Čím větší projekt je, tím méně práce podle mě spočívá v otázce „Jak tuto funkci naprogramuji?“ a tím více v otázce „Čeho všeho se tahle změna dotkne?“

Právě schopnost vidět tyto vazby je něco, co se velmi těžko učí na izolovaných úlohách. Vzniká postupně tím, že člověk několikrát něco změní na jednom místě a zjistí, že tím nečekaně rozbil tři další.

Po nějaké době začne podobné důsledky hledat ještě předtím, než změnu udělá.

Debugging není přerušení skutečné práce. Je to její součást.

Když se člověk učí, může mít pocit, že hlavní činnost developera je psaní nového kódu a chyby jsou jen nepříjemná věc mezi tím.

Reálné projekty mi ukázaly skoro opačný pohled.

Velká část práce je zjišťování, proč se systém nechová tak, jak jsme očekávali.

A často to vůbec není chyba na místě, kde se problém projevil.

Tlačítko nefunguje, protože API vrací chybný stav. API ho vrací kvůli nekonzistentním datům. Nekonzistentní data vznikla při importu před třemi měsíci a projevují se pouze u zákazníků, kteří splňují určitou kombinaci podmínek.

V tu chvíli nepomůže schopnost rychle napsat další kód. Potřebujeme problém systematicky zmenšovat.

Co přesně víme? Dokážeme chybu zopakovat? Kdy se objevila poprvé? Co je společné pro případy, kde nastává? Která část systému je ještě určitě správně? Co se změnilo?

Postupně jsem proto začal debugging vnímat méně jako hledání chyby a více jako práci s hypotézami.

Máme nějaké vysvětlení, ověříme ho, zahodíme nebo zpřesníme a pokračujeme dál.

A tahle schopnost je podle mě přenositelnější než znalost konkrétního frameworku. Technologie se mění, ale potřeba rozebrat neznámý problém na části zůstává.

Omezení vás donutí dělat skutečná rozhodnutí

Ve vlastním projektu můžeme většinu věcí odložit.

Deadline si posuneme. Scope můžeme rozšířit. Pokud se nám přestane líbit technologie, přepíšeme část aplikace. A když něco nefunguje dokonale, často se nic zásadního nestane.

Reálný projekt má zákazníka, rozpočet, termín a nějaký očekávaný výsledek.

Najednou tedy nejde jen o to, jaké řešení by bylo technicky nejlepší. Musíme se rozhodnout, co je nejlepší vzhledem k podmínkám, které skutečně máme.

Má smysl věnovat další dva dny technickému zlepšení, které zákazník prakticky nepozná, když zároveň chybí důležitější část produktu? Máme implementovat obecné řešení pro budoucí situace, nebo udělat jednodušší variantu pro současný problém? Je požadavek natolik důležitý, že kvůli němu posuneme termín?

Na podobné otázky většinou neexistuje jedna správná odpověď.

A právě proto jsou užitečné.

Nutí člověka přestat vnímat software jako čistě technickou disciplínu. Každé rozhodnutí má cenu a každá hodina věnovaná jedné věci chybí někde jinde.

Reálné projekty mě tím naučily mnohem víc přemýšlet nad prioritou než nad samotnou možností něco udělat.

Technicky totiž často můžeme udělat téměř cokoliv.

Podstatně důležitější je poznat, co z toho vůbec dělat máme.

„Funguje mi to“ přestane být dostatečný standard

Vlastní projekt může běžet na našem počítači a tím je problém z velké části vyřešený.

Produkční aplikace musí fungovat i na cizím telefonu, pomalejším internetu, jiném prohlížeči a s daty, která bychom si při testování sami nikdy nevymysleli.

Uživatel dvakrát klikne na tlačítko.

Odešle formulář bez pole, o kterém jsme předpokládali, že vždycky existuje.

Otevře stránku přes starý odkaz.

Nahraje soubor s nečekaným názvem.

Má desetkrát více dat než náš testovací účet.

A samozřejmě udělá věci v pořadí, které nám při návrhu vůbec nepřišlo logické.

To není chyba uživatele.

Je to realita systému.

Právě tady podle mě vzniká velká část rozdílu mezi „umím tuto technologii použít“ a „umím pomocí ní vytvořit něco spolehlivého“.

Druhá schopnost zahrnuje nejen hlavní scénář, ale i ošetření situací okolo. Co se zobrazí při chybě? Může člověk operaci bezpečně zopakovat? Neztratí data? Dokážeme zjistit, co se pokazilo?

Člověk postupně pochopí, že software není hotový ve chvíli, kdy dokáže projít ideální cestou.

Musí přežít i tu neideální.

Komunikace je technická dovednost častěji, než jsem čekal

Jedna z věcí, kterou jsem na začátku s vývojem příliš nespojoval, byla komunikace.

Představoval jsem si ji spíš jako něco okolo samotné práce.

Jenže v reálném projektu může špatná komunikace vytvořit větší technický problém než špatně napsaná funkce.

Pokud developer zjistí uprostřed implementace, že zadání má zásadní technický problém, ale řekne to až v den odevzdání, samotná kvalita jeho kódu už situaci příliš nezachrání.

Stejně tak nepomůže udělat chytré technické rozhodnutí, pokud nikdo další nerozumí jeho důsledkům.

Schopnost říct včas:

„Tohle bude složitější, než jsme čekali, protože…“

„Pokud to uděláme tímto způsobem, vytvoříme si problém tady…“

„Tuhle část zvládneme do termínu, ale tahle bude potřebovat další čas…“

je podle mě normální součást profesionálního vývoje.

Nejde o to hlásit každý malý problém. Jde o to poznat chvíli, kdy informace mění rozhodnutí ostatních lidí, a nenechat ji zbytečně ležet jen ve své hlavě.

To samé platí opačným směrem. Čím dřív se zeptáme na nejasnou část zadání, tím levnější zpravidla bude odpověď. Po týdnu implementace může stejná otázka znamenat předělání poloviny funkce.

Reálný projekt tak rychle ukáže, že dobrý developer není izolovaný člověk, kterému na jedné straně přijde ticket a na druhé vypadne kód.

Je součástí rozhodovacího procesu.

Odpovědnost mění způsob, jakým nad kódem přemýšlíte

Existuje zásadní rozdíl mezi aplikací, kterou můžu po prezentaci zahodit, a systémem, který bude někdo další používat každý den.

Najednou mě mnohem víc zajímá, co se stane za tři měsíce.

Bude změně rozumět další developer? Dokážeme zjistit, proč systém selhal? Jak obtížné bude přidat další funkci? Co se stane s daty při chybě? Jak snadno lze něco opravit bez výpadku?

Ne proto, že bych chtěl všechno stavět dokonale.

Spíš proto, že každé rozhodnutí začne mít pokračování.

Kód, který dnes ušetří dvě hodiny, může příští půlrok komplikovat každou změnu. Naopak několik hodin věnovaných správnému logování nebo testům může později ušetřit desítky hodin při problému v produkci.

Tohle člověk velmi rychle pochopí ve chvíli, kdy je právě on ten, kdo bude ve dvě odpoledne hledat chybu v kódu, který před třemi měsíci napsal ve dvě ráno.

Odpovědnost za dlouhodobý výsledek podle mě vytváří jiný druh technického úsudku než snaha pouze úspěšně dokončit zadání.

Reálný projekt vás naučí, že hotovo není binární stav

V tutorialu je většinou zřejmé, kdy jsme skončili.

Výsledek vypadá jako na obrazovce autora a můžeme pokračovat další kapitolou.

U skutečného produktu existuje skoro vždy něco, co by šlo ještě vylepšit. Lepší ošetření chyb. Čistší kód. Rychlejší načítání. Další krajní případ. Hezčí animace. Přesnější analytika.

Kdybychom čekali na stav, kdy už nejde nic zlepšit, nevydáme nic.

Součást práce je proto určit, co musí být hotové teď a co může počkat.

To není rezignace na kvalitu. Je to praktická definice kvality vzhledem k účelu.

Jiný standard potřebuje interní prototyp a jiný platební systém. Jiný detail si můžeme dovolit odložit týden před spuštěním a jiný by mohl zákazníkovi způsobit ztrátu dat.

Právě reálné projekty mě naučily, že dobře odvést práci neznamená maximalizovat kvalitu každého jednotlivého detailu, ale rozdělit omezený čas tak, aby byl celkový výsledek co nejlepší.

Dokumentace začne dávat smysl ve chvíli, kdy něco zapomenete

Dokumentace při cvičném projektu snadno působí jako zbytečná práce.

Kód jsme právě napsali, přesně víme, proč funguje tímto způsobem, a celý projekt má několik souborů.

O několik měsíců později se ale člověk vrátí k vlastnímu řešení a začne přemýšlet, proč proboha něco udělal právě takhle.

A ještě horší je, když se k němu musí vrátit někdo jiný.

Teprve tehdy začne být jasná hodnota jednoduchých věcí: rozumného pojmenování, stručného popisu netriviálního rozhodnutí, aktuálního README, jasných proměnných prostředí nebo poznámky, proč jsme zvolili jednu variantu místo jiné.

Nejsem zastáncem dokumentování všeho.

Dokumentace, která okamžitě zastará, může vytvořit víc problémů než užitku.

Ale důležitá rozhodnutí, která nejsou z kódu zřejmá, podle mě stojí za zachycení. Ne pro nějakého hypotetického budoucího developera.

Často pro nás samotné o šest měsíců později.

Nejvíc se člověk naučí tam, kde návod končí

Tohle je možná hlavní rozdíl mezi řízeným učením a reálnou prací.

Tutorial vás může velmi dobře naučit, jak něco udělat, pokud problém odpovídá jeho scénáři.

Reálný projekt vás nutí řešit, co dělat, když žádný scénář přesně nesedí.

Dokumentace popisuje API, ale neřekne vám automaticky, jestli je správným řešením vašeho konkrétního produktu.

Stack Overflow nebo AI vám mohou pomoct opravit chybu, ale nejdřív musíte poznat, jakou otázku vlastně položit.

Framework vám dá deset způsobů implementace, ale nevybere za vás ten, který odpovídá vašim omezením.

Právě tahle práce s neúplnými informacemi podle mě vytváří skutečnou zkušenost.

Člověk si neukládá jen další řešení do paměti. Postupně si vytváří modely: které problémy se obvykle skrývají za určitými příznaky, která rozhodnutí mají dlouhodobé následky, kdy je potřeba zpomalit a kdy naopak nemá cenu něco zbytečně komplikovat.

A s každým dalším projektem se tento úsudek zpřesňuje.

Reálné projekty neučí jen programovat lépe

Kdybych měl shrnout, co mi reálné projekty oproti samotnému učení daly, nebyla by to jedna konkrétní technická dovednost.

Spíš změnily způsob, jakým nad vývojem přemýšlím.

Naučily mě, že zadání není automaticky pravda a často je potřeba nejdřív pochopit problém pod ním. Že zdánlivě malá změna může mít velký dopad jinde v systému. Že debugging není něco, co přichází po programování, ale normální část práce. Že termíny, rozpočet a omezení nejsou nepříjemnosti okolo vývoje, ale vstupy do technického rozhodování.

A hlavně, že mezi „vím, jak se to dělá“ a „dokážu zajistit, aby to fungovalo v reálném prostředí“ je poměrně velká mezera.

Tutorialy, kurzy a dokumentace jsou skvělé nástroje pro získávání znalostí. Bez nich bychom spoustu věcí zbytečně objevovali znovu.

Jen mají jiný účel.

Naučí nás dostupné stavební bloky.

Skutečný projekt nás potom donutí rozhodnout, které z nich použít, v jakém pořadí, s jakými kompromisy a co udělat ve chvíli, kdy realita neodpovídá příkladu.

Právě proto bych člověku, který už zná základy a chce se ve vývoji opravdu posunout, nedoporučil pouze další kurz.

Doporučil bych mu postavit něco, na čem skutečně záleží.

Ideálně něco, co bude používat někdo jiný.

Protože ve chvíli, kdy výsledkem není zelená fajfka v tutorialu, ale člověk čekající na fungující produkt, začne vývoj vypadat úplně jinak.

A právě tam podle mě začíná největší část skutečného učení.

Zdroje

• Frederick P. Brooks Jr. — The Mythical Man-Month
• David A. Kolb — Experiential Learning: Experience as the Source of Learning and Development
• Lahtinen, Ala-Mutka & Järvinen — A Study of the Difficulties of Novice Programmers