Proč se odhady času v softwaru vždycky seknou a co s tím

Typická chyba je lpění na poměru počtu testů. Pyramida není o číslech, ale o tom, kde je test nejrychlejší a nejstabilnější. Pokud se požadavek týká nové kombinace vstupů, patří test dolů, i když se tím poměr vychýlí. Naopak pokud se změna týká celého toku přes několik systémů, může být výhodnější jeden dobře napsaný integrační test než deset end-to-end scénářů, které padají z nesouvisejících důvodů. Pravidlo zní: testujte na nejnižší vrstvě, která ještě věrně zachytí dané riziko.

Než začnete cokoliv odhadovat, rozbijte práci na části, které trvají nejvýš jeden den. Velké celky typu „nasadit platební bránu" nebo „přepsat autentizaci" se odhadují naprosto mizerně, protože v sobě skrývají desítky neznámých. Malý kousek se dá představit, velký ne. U každé části si napište, co přesně znamená hotovo – ne „funguje to", ale konkrétní stav, kdy můžete říct, že je hotovo. Tím zmizí polovina sporů o to, jestli je úkol opravdu dokončený.

Kód, který funguje, ještě není kód, který se dá číst. Rozdíl mezi oběma poznáte ve chvíli, kdy se k souboru vrátíte po třech týdnech a nevíte, co dělá proměnná s názvem data2. Čistý kód není otázka vkusu ani estetiky. Je to praktická investice, která se vyplatí pokaždé, když někdo jiný — nebo vy sami — musí do logiky zasáhnout.

Nakonec platí, že čím víc nejistoty, tím širší musí být rozpětí. U dobře známé práce se vejdete do úzkého pásma, u nové technologie klidně počítejte s dvojnásobkem. Kdo slibuje přesné datum u něčeho, co ještě nikdy nedělal, buď lže, nebo neví, co ho čeká. Přiznaná nejistota není slabost, je to přesně ta informace, kterou zadavatel potřebuje, aby se mohl rozhodnout.

Nepodceňujte nástroje pro vývoj. Redux DevTools umožňují sledovat každou akci, skákat v čase a porovnávat strom stavu před a po. Když se aplikace chová divně, první krok je najít akci, po které se stav rozbije. Často se ukáže, že reducer mutuje původní objekt místo vytvoření nového. V produkci middleware pro logování vypněte, jinak zbytečně zpomaluje aplikaci a zaplavuje konzoli. Stejně tak kontrolujte, že žádný reducer neobsahuje náhodné hodnoty nebo volání API.

Pozor taky na tlak na co nejnižší číslo. Když se odhady používají jako nástroj k hodnocení výkonu, lidé je začnou podstřelovat, aby vypadali dobře, a celý systém přestane fungovat. Odhad má sloužit k plánování, ne k souzení. Stejně tak nepomáhá odhadovat ve skupině tak, že promluví nejhlasitější a ostatní přikývnou. Lepší je, když každý napíše svoje číslo nejdřív soukromě a pak se porovnávají rozdíly – ty ukážou, kde jsou skryté nejasnosti.

Permisivní licenci zvolte, pokud chcete, aby kód pronikl co nejdál. Typicky jde o knihovny a nástroje, které mají skončit ve firemních produktech, v mobilních aplikacích nebo v jiných projektech s odlišnou licencí. Firma, která by narazila na copyleft, váš kód raději obejde nebo napíše vlastní. Permisivní licence tomu brání a často vedou k tomu, že se z vašeho kódu stane neviditelný základ, na kterém staví ostatní. To je výhoda, pokud je vaším cílem rozšíření a reputace, ne kontrola.

Odhady času v softwarových projektech selhávají tak spolehlivě, až to přestává být náhoda. Za většinou skluzů nestojí lenost ani neschopnost, ale pár systematických chyb, které se opakují pořád dokola. První krok k lepším odhadům není lepší metodika, ale přiznání, že odhad je vždycky rozpětí, ne konkrétní datum. Dokud budete říkat „bude to hotové v pátek", budete se mýlit. Když řeknete „s velkou pravděpodobností to bude mezi středou a příštím úterým", máte najednou prostor, který odpovídá realitě.

Chyba, která se vrací pořád Nejčastější chybou je odhadovat jen samotné programování. Kódování bývá možná polovina skutečné práce. Zbytek tvoří čtení cizího kódu, hledání v dokumentaci, psaní testů, opravy po code review, ladění na prostředí, které se chová jinak než lokálně, a čekání na odpovědi. Když si k odhadu nepřipočtete tyhle položky, dostanete číslo, které nikdy nevyjde. Praktický trik: vezměte odhad samotného kódování a vynásobte ho dvěma. Není to věda, ale bývá to blíž pravdě než původní číslo.

Copyleft chrání svobodu, kterou sám dává Copyleft zvolte, když nechcete, aby někdo vzal vaši práci, vylepšil ji a zavřel. Platí to pro celé aplikace, ale i pro knihovny, u kterých vám vadí, že by se zlepšení nikdy nevrátila zpět. GPL je vhodná pro samostatné programy, AGPL řeší díru, kdy někdo provozuje upravenou verzi jen jako webovou službu a zdrojový kód nikdy nevydá. LGPL se používá u knihoven, které chcete nechat propojitelné i s uzavřeným softwarem, ale samotné úpravy knihovny musí zůstat otevřené.