Joel on Software

Joel on Software   Součást "Joel on Software" (Joel píše o softwaru)

 

Ostatní články z "Joel on Software" v češtině

Ostatní články z "Joel on Software" v angličtině

Napište autorovi (pouze anglicky)

 

Joelův test - 12 kroků k lepším programům


Joel Spolsky
Přeložil Jaroslav Šnajdr
09.08.2000

Slyšeli jste někdy o systému SEMA? Je to dost esoterická metodika pro měření kvality programátorského týmu. Moment! Neklikejte na ten link! Bude vám trvat tak šest let, než tu věc vůbec pochopíte. Proto jsem vymyslel svůj vlastní, velmi nezodpovědný a nepřesný test pro ohodnocení kvality týmu. Co je na něm skvělé je, že trvá jen asi tři minuty. Během doby, kterou teď ušetříte, můžete jít třeba vystudovat medicínu.

Joelův test

  1. Používáte systém pro správu verzí?
  2. Dokážete udělat build v jednom kroku?
  3. Děláte každodenní buildy?
  4. Máte databázi chyb?
  5. Opravujete chyby předtím, než začnete psát nový kód?
  6. Máte průběžně aktualizovaný plán prací?
  7. Píšete specifikace?
  8. Mají programátoři klidné pracovní prostředí?
  9. Používáte ty nejlepší nástroje, které jsou k dispozici?
  10. Máte testery?
  11. Píší uchazeči o práci kód během přijímacího pohovoru?
  12. Děláte "pouliční" testy uživatelského rozhraní?

Výhoda Joelova testu je, že na všechny otázky lze snadno a rychle odpovědět ano nebo ne. Nemusíte počítat počet-řádek-kódu-za-den nebo průměrný-počet-chyb-v-inflexním-bodu. Za každou odpověď "ano" získáváte jeden bod. Nevýhoda Joelova testu je, že není vůbec dobré jím měřit spolehlivost softwaru pro řízení atomové elektrárny.

Výsledek 12 bodů je perfektní, 11 ještě ujde, ale 10 a méně už je vážný problém. Pravda je bohužel taková, že většina softwarových společností má skóre 2 nebo 3 body a potřebují vážnou pomoc, protože firmy jako Microsoft jedou nepřetržitě na plných 12 bodech.

Samozřejmě, tahle kritéria nejsou jediná, která rozhodují o úspěchu a neúspěchu: máte-li například skvělý tým, který pracuje na produktu, který nikdo nechce, no tak ten si prostě nikdo nekoupí. A je možné si představit partu "pistolníků", která nic z tohohle nedělá a přesto dokáže napsat skvělý program který změní svět. Ale pomineme-li všechno ostatní, děláte-li těchto 12 věcí správně, máte disciplinovaný tým který je schopen podávat stabilní výkon.

1. Používáte systém pro správu verzí?

Používal jsem komerční balíky pro správu verzí, a používal jsem CVS, které je zadarmo. A můžu vám říct, že CVS bohatě stačí. Ale jestli nic takového nemáte, dá vám strašně práce zajistit, aby programátoři navzájem spolupracovali. Nikdo nebude vědět, co udělali ostatní. Když uděláte chybu, nemůžete se vrátit zpět. Další příjemná stránka správy verzí je, že zdrojový kód je zkopírovaný na lokálním disku každého programátora -- nikdy jsem neslyšel o projektu, který používá správu verzí a ztratil nějaké zdrojáky.

2. Dokážete udělat build v jednom kroku?

Tím mám na mysli: kolik kroků je třeba provést k tomu, abyste získali výsledný produkt z poslední verze zdrojáků? Dobré týmy mají jediný skript, který provede plný checkout na čistý počítač, zkompiluje každou řádku kódu, vytvoří EXE soubory, na všech platformách, jazykových verzích a #ifdef kombinacích, vytvoří instalační balík, a vytvoří výsledné médium - image pro CD-ROM, stránku pro download, cokoliv.

Pokud tento proces má více než jeden krok, je náchylný k chybám. A když se blížíte k vydání, potřebuje velmi rychlý cyklus, kdy opravíte "poslední" chybu, vytvoříte finální EXE, a tak dále. Jestli potřebujete 20 kroků pro kompilaci, buildování instalačky atd., zblázníte se z toho a budete dělat hloupé a zbytečné chyby.

Minulá společnost, pro kterou jsem pracoval, jen z tohoto důvodu přešla z WISE Installeru na InstallShield: vyžadovali jsme, aby instalační proces šlo spustit ze skriptu, automaticky, přes noc, z NT plánovače, a ve WISE tohle nešlo. Tak jsme ho vyhodili (Pánové z WISE mě ujišťují, že jejich současné verze už podporují noční buildy.)

3. Děláte každodenní buildy?

Když používáte systém pro správu verzí, občas někdo omylem commitne něco co nejde přeložit. Například přidá nový zdrojový soubor, na jeho počítači se všechno v pohodě přeloží, ale zapomněl ten soubor přidat do CVS. Takže vypne počítač a jde domů, nic netušící a vysmátý. Ale ostatní nemůžou pracovat, takže musí jít také domů, ale naštvaní.

Narušení buildu je tak špatná (a obvyklá) věc, že je vhodné dělat každodenní buildy a zajistit tak, že každé narušení bude ihned odhaleno. Jednou z cest pro větší týmy, jak narušení okamžitě napravit, je dělat build každé odpoledne například během oběda. Každý udělá co nejvíc commitů před obědem. Když se vrátí zpátky, je všechno hotovo. Je-li všechno v pořádku, dobrá. Každý si vytáhne poslední verzi a pracuje dál. Když se něco nepovedlo, opravte to a každý může dál pracovat s funkční verzí zdrojáků před buildem.

V týmu, který psal Excel, jsme měli pravidlo, že ten, kdo zkazil build, se musel "za trest" starat o buildovací systém až do té doby, kdy to zkazil někdo jiný. To je dobrá motivace k tomu, abychom nekazili buildy a vhodná metoda, jak vystřídat všechny členy týmu u buildovacího procesu a tak seznámit všechny s tím, jak funguje.

Více o každodenních buildech si můžete přečíst v mém článku Denní build je tvůj kamarád.

4. Máte databázi chyb?

Ne, nechci slyšet žádné výmluvy. Když programujete, klidně i v týmu o jednom člověku, a nemáte organizovanou databázi se všemi známými chybami v kódu, budete produkovat nekvalitní software. Hodně programátorů si myslí, že udrží všechny chyby v hlavě. Nesmysl. Nedokážu si pamatovat víc než dvě tři chyby najednou. A zítra ráno, nebo až budu ve spěchu vydávat novou verzi, už si na ně nevzpomenu. Bezpodmínečně musíte evidovat chyby na více formální bázi.

Databáze chyb můžou být složité i jednoduché. Minimální použitelná databáze musí obsahovat následující informace o každé chybě:

  • úplný postup, jak chybu reprodukovat
  • očekávané chování
  • pozorované (nesprávné) chování
  • komu je chyba přiřazena
  • jestli byla chyba opravena nebo ne

Jestli je složitost bug tracking systémů jediné, co vám brání je používat, jednoduše si udělejte tabulku s těmito základními pěti sloupci a začněte ji používat.

Chcete-li se dozvědět více, přečtěte si Bezbolestnou evidenci chyb.

5. Opravujete chyby předtím, než začnete psát nový kód?

Vývoj úplně první verze Microsoft Wordu pro Windows byl považován za "pochod smrti". Trvalo to celou věčnost. Neustále se opožďoval. Celý tým pracoval od rána do noci, vydání se odkládalo, znovu a znovu a znovu, a stres byl neuvěřitelný. Když po mnoha letech ta věc konečně vyšla, Microsoft poslal celý tým na dovolenou do Cancunu (přímořské letovisko v Mexiku), sedli si dohromady a začali zpytovat svědomí.

Přišli na to, že projektoví vedoucí tak rázně trvali na dodržení "harmonogramu", že programátoři neuveřitelně pospíchali a psali extrémně špatný kód, protože čas na opravu chyb nebyl vůbec součástí oficiálního plánu. Nikdo se nesnažil udržet počet chyb na rozumně malém čísle. Právě naopak. Vypráví se, že jeden programátor, který měl napsat kód pro výpočet výšky řádky textu, napsal prostě "return 12;" a čekal až někdo nahlásí problém, že tato funkce v některých případech nefunguje úplně dobře. Plán prací byl pouze seznam vlastností, které se měly stát chybami. Později byl tento postup pojmenován jako "infinite-defect metodologie".

Aby se vyřešil tento problém, celý Microsoft přijal takzvanou "zero-defect metodologii". Mnoho programátorů ve firmě se nad tím usmívalo, protože to vypadalo jako že si management myslí, že počet chyb lze snížit vynesením nějakého dekretu. Ve skutečnosti "zero-defect" znamenalo, že v jakýkoliv okamžik je vždy nejvyšší prioritou odstranit chyby předtím, než se začne psát nový kód. Řekneme si proč.

Obecně platí, že čím déle otálíte s opravou chyby, tím více prostředků (času i peněz) to stojí.

Když například uděláte překlep nebo syntaktickou chybu, kterou najde překladač, opravit ji je naprosto triviální.

Když máte v programu chybu, kterou najdete hned napoprvé co program spustíte, budete schopni ji okamžitě opravit, protože celý kód máte ještě pořád čerstvě v hlavě.

Když je chyba v kódu, který jste napsali před pár dny, bude vám chvilku trvat, než ji najdete, ale když si znovu přečtete kód který jste napsali, bude vám brzy všechno jasné a dokážete chybu opravit v rozumném čase.

Ale když najdete chybu v kódu, který jste napsali před několika měsíci, už jste nejspíš zapomněli hodně věcí a bude o dost těžší ji opravit. Po takové době se vám může stát, že budete opravovat chyby v kódu někoho jiného, kdo může být zrovna na dovolené v Karibiku. A v tomto případě už je to docela věda: musíte postupovat pomalu, metodicky a precizně, a nemůžete si být jisti, jak dlouho vám bude trvat najít řešení.

A když najdete chybu v programu, který už byl vydán, oprava vás přijde opravdu draho.

To je první důvod, proč opravovat chyby okamžitě: protože to zabere méně času. Je tu ještě další důvod, který souvisí s tím, že je jednodušší předpovědět čas potřebný k napsání nového kódu než jak dlouho bude trvat oprava chyby. Když se vás třeba zeptám, jak dlouho vám bude trvat napsat funkci na seřazení seznamu, budete schopni mi dát docela dobrý odhad. Ale když položím otázku, jak dlouho bude trvat opravit tu chybu, kdy váš program nefunguje dobře, když je zároveň nainstalovaný Internet Explorer 5.5, nemůžete ani hádat, protože nevíte (principiálně), čím je chyba způsobena. Může to trvat 3 dny, nebo třeba 2 minuty.

To znamená, že když máte plán prací a je hodně neopravených chyb, váš plán není spolehlivý. Ale poté, co jste opravili všechny známé chyby, a zbývá jen přidat nové vlastnosti, bude váš plán nesrovatelně přesnější.

Další skvělá věc při nulovém počtu chyb je ta, že jste schopni mnohem rychleji reagovat na konkurenci. Někteří říkají, že produkt je neustále připraven k vydání. Když váš konkurent potom uvede novou super vlastnost, se kterou vám začne přebírat zákazníky, můžete implementovat právě tu jednu vlastnost a okamžitě vydat novou verzi, aniž byste museli opravovat mraky nashromážděných chyb.

6. Máte průběžně aktualizovaný plán prací?

Tím jsme se dostali k plánování. Jestli má váš software význam pro váš obchod, je mnoho důvodů, proč je důležité aby obchod věděl, kdy to bude hotové. Programátoři jsou notoricky nevrlí, když mají dělat plány. "Až to bude, tak to bude!", křičí na obchodníky.

Bohužel, takhle to prostě nejde. Obchod musí naplánovat a rozhodnout příliš mnoho záležitostí dlouho předtím, než je program hotový: prezentace, výstavy, reklamní kampaň atd. A jediný způsob, jak toho dosáhnout, je plán, který je pravidelně aktualizovaný.

Další zásadní důsledek plánu je, že vás přinutí se rozhodnout, jaké vlastnosti budete implementovat, a také vás přinutí vzít méně důležité vlastnosti a vyhodit je, místo abyste sklouzli do nemoci zvané featuritis.

Udržování plánu nemusí být těžké. Přečtěte si můj článek Bezbolestné plánování softwaru, který popisuje jednoduchý způsob, jak dělat skvělé plány.

7. Píšete specifikace?

Psaní specifikací je jako čištění zubů dentistickou nití: všichni souhlasí, že to je správné, ale nikdo to nedělá.

Nejsem si jistý, čím je to způsobeno, ale nejspíš to bude tím, že většina programátorů nesnáší psaní dokumentů. Výsledek je, že když tým samých programátorů řeší problém, dávají přednost vyjádřit své myšlenky kódem, raději než by psali nějaké dokumenty. Nejradši by se do toho ponořili a psali kód, místo aby napřed napsali specifikaci.

Ve fázi návrhu, když narazíte na problémy, můžete je snadno vyřešit změnou několika řádek textu. Jakmile je kód jednou napsaný, cena za řešení je dramaticky vyšší, jak emocionálně (lidé strašně neradi zahazují už hotový kód), tak časově. Proto se řešení problémů setkává s odporem. Software, který byl napsán bez specifikace, obvykle skončí špatně navržený a časový plán se vymyká z rukou. Něco takového se asi stalo Netscape, kdy první čtyři verze postupně vyrostly do takového bordelu, že management učinil hloupé rozhodnutí, že všechno zahodí a napíšou znovu. A pak tu samou chybu přesně zopakovali ještě jednou s Mozillou, monstrem, které se vymklo kontrole a trvalo mu několik let, než se dostalo do alfa verze.

Moje oblíbená teorie je, že tento problém lze vyřešit tak, že programátory naučíme být méně zdrženlivými spisovateli tím, že je pošleme na intenzivní kurs tvůrčího psaní. Jiné řešení je zaměstnat šikovné program managery, kteří budou produkovat písemné specifikace. V obou případech byste měli zavést jednoduché pravidlo "ani řádka kódu bez specifikace".

Naučte se vše o psaní specifikací v mém čtyřdílném seriálu.

8. Mají programátoři klidné pracovní prostředí?

Je zevrubně zdokumentováno, že produktivita znalostních pracovníků roste, mají-li dost prostoru, klidu a soukromí. Klasická kniha o řízení sofwarových projektů Peopleware tyto vlivy na produktivitu obsáhle popisuje.

O co jde. Všichni víme, že tvůrčí pracovníci pracují nejlépe, když se dostanou do "transu", neboli "do zóny", což je duševní stav, kdy jsou plně koncentrovaní na svou práci a izolovaní od okolního prostředí. Ztrácejí pojem o čase a produkují velké hodnoty díky absolutní koncentraci. To je doba, kdy vykonají veškerou produktivní práci. Spisovatelé, programátoři, vědci a dokonce i hráči basketbalu vám mohou vyprávět, co to je "být v zóně".

Špatná zpráva je, že dostat se do "zóny" není snadné. Když se to pokusíme změřit, zjistíme, že trvá přibližně 15 minut, než dosáhneme maximální produktivity. Někdy, když jste unavení nebo už jste ten den udělali příliš mnoho tvůrčí práce, nepodaří se vám tam dostat a strávíte zbytek pracovního dne chytáním lelků, čtením webu a hraním Tetrisu.

Další špatné zpráva je, že je velmi snadné být vyrušen ven "ze zóny". Hluk, telefony, odchod na oběd, nutnost jet 5 minut na kávu do Starbucks, vyrušování spolupracovníky -- hlavně vyrušování spolupracovníky -- to všechno vás vyhodí ven. Když se vás spolupracovník na něco zeptá, čímž vás vyruší na 1 minutu, bude vám ve skutečnosti trvat skoro půl hodiny, než se dostanete zpět do původního stavu. Vaše produktivita je v troskách. Pracujete-li v rušném otevřeném prostoru, oblíbeném u dotcom firem, kde marketingoví pracovníci hulákají do telefonu hned vedle programátorů, vaše produktivita prudce klesne, protože znalostní pracovníci budou v jednom kuse vyrušování a nedokážou se soustředit.

S programátory je to obzvlášť těžké. Produktivita je závislá na schopnosti dostat do krátkodobé paměti v jeden okamžik spoustu drobných detailů. Jakékoliv vyrušení celou tuto pyramidu ihned zhroutí. Když chcete pokračovat v práci, všechny ty detaily (jako jména lokálních proměnných, které právě používáte, nebo v jakém kroku vyhledávacího algoritmu jste právě byli) už jsou pryč a musíte je znovu pracně dohledávat. To vás stojí značné zpomalení, než se dostanete zpátky na plnou rychlost.

Zde jsou jednoduché počty. Řekněme (jak naznačuje pozorování), že když vyrušíme programátora, třeba i na jednu minutu, ve skutečnosti přijdeme o 15 minut produktivity. Posaďme dva programátory, Honzu a Pepu, do jedné otevřené buňky v typické Dilbertovské farmě. Pepa neví, jak se jmenuje Unicode verze funkce strcpy. Mohl by si to sám najít, což trvá 30 sekund, nebo se zeptat Honzy, což trvá 15 sekund. Protože sedí vedle Honzy, zeptá se tedy Honzy. Honza je vyrušen a ztrácí 15 minut produktivity (a ušetří Pepovi 15 sekund).

Přestěhujme je teď do oddělených kanceláří se zdmi a dveřmi. Když si teď Pepa nemůže vzpomenout na jméno funkce, může si ji najít, což pořád trvá 30 sekund. Nebo se může zeptat Honzy, což teď trvá 45 sekund a vyžaduje to, aby vstal ze židle (což není lehká úloha, přihlédneme-li k fyzické kondici průměrného programátora!). Takže Pepa ztratí 30 sekund, ale zároveň ušetří Honzovi 15 minut. Ha!

9. Používáte ty nejlepší nástroje, které jsou k dispozici?

Programování v kompilovaném jazyce je jedna z mála zbývajících věcí, které nejdou dělat rychle na řadovém domácím počítači. Když kompilace trvá déle než několik sekund, nejnovější a nejrychlejší počítač vám ušetří spoustu času. Trvá-li překlad i jen 15 sekund, programátor se bude během překladu nudit a začne si číst Onion, což ho pohltí a ztratí několik pracovních hodin.

Ladění grafického kódu na systému s jedním monitorem je velmi těžké, až nemožné. Děláte-li grafiku, dva monitory vám hodně ulehčí práci.

Většina programátorů dříve nebo později potřebuje editovat bitmapy pro ikony nebo panely nástrojů, a většina programátorů nemá k dispozici dobrý editor bitmap. Používat na tohle Microsoft Paint je špatný vtip, ale většině programátorů nic jiného nezbývá.

V mém posledním zaměstnání mi správce sítě neustále posílal automatické spamy s varováním, že používám více než ... teď pozor ... 220 megabajtů diskového prostoru na serveru. Poznamenal jsem, že při dnešních cenách disků je cena tohoto prostoru výrazně menší než cena toaletního papíru, který ve firmě spotřebuji. Strávit pouhých 10 minut uklízením svého adresáře by bylo neomluvitelné plýtvání časem.

Špičkové vývojové týmy netrápí své programátory. Malé frustrace způsobené nedostatečnými nástroji se sčítají a lidé jsou pak podráždění a naštvaní. A naštvaný programátor není produktivní programátor.

A ještě něco... programátory je snadné uplatit tím, když jim dáváte zajímavé a nové technické nástroje. To je daleko levnější cesta jak je přilákat do své firmy než platit konkurenční mzdy!

10. Máte testery?

Jestli váš tým nemá dedikované testery, alespoň jednoho na každé dva nebo tři programátory, tak buď vydáváte produkty s hodně chybami, nebo vyhazujete peníze tím, že drazí programátoři dělají práci, kterou zvládnou třikrát levnější testeří. Šetření na testerech je tak zoufale falešná ekonomika, že je zcela mimo moje chápání, jak to že to tolika lidem nedochází.

Přečtěte si Nejoblíbenějších pět (špatných) důvodů, proč nemít testery, článek, který jsem napsal o tomto tématu.

11. Píší uchazeči o práci kód během přijímacího pohovoru?

Najali byste si kouzelníka, aniž by vám předem ukázal nějaké svoje triky? Samozřejmě že ne.

Objednali byste si kuchaře na svou svatbu, aniž byste napřed ochutnali jeho jídlo. Pochybuju.

Navzdory tomu jsou dnes a denně přijímáni do práce programátoři jen na základě toho, že mají imponující životopis nebo protože se s nimi přijímajícímu hezky povídalo. Nebo jsou jim kladeny jednoduché otázky ("jaký je rozdíl mezi CreateDialog() a DialogBox()?"), na které se dají najít odpovědi v dokumentaci. Nezajímá vás přece, jestli si pamatují tisíce detailů o programování, zajímá vás, jestli jsou schopni napsat program. Ještě horší je řešení hádanek typu "Aha!": problémů, které jsou jednoduché, když znáte řešení, ale když ho neznáte, jsou neřešitelné.

Prosím, přestaňte tohle dělat. Dělejte si při přijímacím pohovoru co chcete, ale dejte kandidátovi napsat nějaký kód. (Pro další rady si přečtěte můj Partyzánský průvodce přijímacím pohovorem).

12. Děláte "pouliční" testy uživatelského rozhraní?

"Pouliční" test uživatelského rozhraní je když zastavíte prvního člověka, kterého potkáte na chodbě a necháte ho zkusit používat program, který jste právě napsali. Když tohle uděláte s pěti lidmi, zjistíte 95% problémů s použitelností vašeho uživatelského rozhraní.

Dobrý návrh uživatelského rozhraní není tak těžký jak by se možná zdálo, a je nezbytný, jestli chcete, aby zákazníci kupovali a milovali váš produkt. Můžete si přečíst mou zdarma přístupnou online knihu o návrhu GUI, krátký úvod do tématu pro programátory.

Nejdůležitější na uživatelském rozhraní je ale to, že když ukážete svůj program několika lidem (pět nebo šest stačí), rychle najdete největší problémy, které s ním lidé mají. Přečtěte si článek Jakoba Nielsena, který vysvětluje, proč. I když neumíte moc navrhovat uživatelská rozhraní, přinutíte-li sami sebe dělat "pouliční" testy použitelnosti, které nic nestojí, vaše UI bude mnohem, mnohem kvalitnější.

Čtyři způsoby užití Joelova testu
  1. Ohodnoťte svoji firmu a řekněte mi výsledek, abych vás mohl drbat.
  2. Jste-li vedoucí programátorského týmu, použijte tento test ke zajištění, aby váš tým fungoval co nejlépe. Jakmile dosáhnete 12 bodů, můžete nechat programátory na pokoji a plně se zaměřit na to, aby je neotravovali lidé z obchodu.
  3. Rozhodujete-li se, jestli přijmete nabídku programátorské práce, zeptejte se potenciálního zaměstnavatele, jak si stojí v tomto testu. Jestli je skóre nízké, ujistěte se, že budete mít pravomoc to změnit. Jinak budete frustrovaní a neproduktivní.
  4. Jste-li investor, který dělá ocenění hodnoty programátorského týmu, nebo když vaše softwarová společnost zvažuje spojení s jinou, tento test může poskytnout rychlé a jednoduché vodítko.


Tento článek původně vyšel v angličtině pod jménem The Joel Test: 12 Steps to Better Code  

Joel Spolsky je zakladatel Fog Creek Software, malé softwarové společnosti v New Yorku. Absolvoval univerzitu v Yale a pracoval jako programátor ve společnostech Microsoft, Viacom a Juno.


Obsah těchto stránek vyjadřuje osobní názory jednoho člověka.
©1999-2005 Joel Spolsky. Všechna práva vyhrazena.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky