možnost půjčovat si e-knihy (ZDARMA) z knihoven. Výkonem i funkcemi patří ereading.cz 4 ke

Transkript

1

2 Recenze: Česká čtečka ereading.cz je vlastně tablet s elektronickým papírem. Netradiční funkce doplnila možnost půjčovat si e-knihy (ZDARMA) z knihoven. Výkonem i funkcemi patří ereading.cz 4 ke

3 špičce...

4 Kevlin Henney 97 klíčových znalostí programátora Computer Press, a. s. Brno 2010

5 97 klíčových znalostí programátora Kevlin Henney Computer Press, a. s., Vydání první. Jazyková korektura: Veronika Macková Vnitřní úprava: Dagmar Hajdajová Sazba: Ctibor Foltýn Rejstřík: Daniel Štreit Obálka: Zuzana Šindlerová Komentář na zadní straně obálky: Martin Herodek Technická spolupráce: Jiří Matoušek Odpovědný redaktor: Martin Herodek Technický redaktor: Jiří Matoušek Produkce: Petr Baláš Authorized Czech translation of 97 Things Every Programmer Should Know ISBN , Kevlin Henney. This translation is published and sold by permission of O Reilly Media, Inc., the owner of all rights to publish and sell the same. Autorizovaný překlad z originálního anglického vydání 97 Things Every Programmer Should Know. Originální copyright: 2010 Kevlin Henney. Překlad: Computer Press, a. s., Computer Press, a. s., Holandská 3, Brno Objednávky knih: distribuce@cpress.cz tel.: ISBN Prodejní kód: K1834 Vydalo nakladatelství Computer Press, a. s., jako svou publikaci. Computer Press, a. s. Všechna práva vyhrazena. Žádná část této publikace nesmí být kopírována a rozmnožována za účelem rozšiřování v jakékoli formě či jakýmkoli způsobem bez písemného souhlasu vydavatele.

6 Obsah Tipy podle zaměření Úvod Jednejte s opatrností Seb Rose Aplikujte principy funkcionálního programování Edward Garson Položte si otázku: Co by udělal uživatel? (vy jím nejste) Giles Colborne Automatizujte své kódovací standardy Filip van Laenen V jednoduchosti je krása Jørn Ølmheim Před refaktorováním Rajith Attapattu Pozor na sdílený kód Udi Dahan Skautské pravidlo Robert C. Martin (Uncle Bob) Než začnete obviňovat ostatní, zkontrolujte vlastní kód Allan Kelly Obsah 3

7 Nástroje volte s rozvahou Giovanni Asproni Programujte v jazyce domény Dan North Kód představuje návrh Ryan Brush Na odsazení kódu záleží Steve Freeman Revize kódu Mattias Karlsson Odůvodnění správnosti kódu Yechiel Kimchi Pár slov ke komentářům Cal Evans Komentujte pouze to, co kód sám nedokáže říct Kevlin Henney Nepřetržité učení Clint Shank Pohodlnost nepatří mezi ctnosti Gregor Hohpe Nasazujte brzy a často Steve Berczuk Rozlište technické a business výjimky Dan Bergh Johnsson Procvičujte se Jon Jagger Jazyky specifické pro doménu Michael Hunger Nebojte se, že něco rozbijete Mike Lewis Nesnažte se okouzlit testovacími daty Rod Begbie 4 97 klíčových znalostí programátora

8 Neignorujte chyby Pete Goodliffe Nestačí pouze naučit se jazyk, ale porozumět jeho kultuře Anders Norås Nesnažte se svůj program přibít do vzpřímené polohy Verity Stob Nevěřte na kouzla Alan Griffiths Neopakujte se Steve Smith Nedotýkej se toho kódu Cal Evans Zapouzdřete chování, ne pouze stav Einar Landre Čísla s plovoucí řádovou čárkou nejsou reálná Chuck Allison Naplňte své ambice pomocí open-source Richard Monson-Haefel Zlaté pravidlo návrhu API Michael Feathers Mýtus guru Ryan Brush Dřina se nevyplácí Olve Maudal Použití systému pro sledování chyb Matt Doar Vylepšete kód tím, že ho odstraníte Pete Goodliffe Nainstaluj si mě Marcus Baker Komunikace mezi procesy ovlivňuje reakční dobu aplikace Randy Stafford Obsah 5

9 Udržujte build čistý Johannes Brodwall Naučte se používat nástroje příkazového řádku Carroll Robinson Ovládejte více než dva programovací jazyky Russel Winder Poznejte své IDE Heinz Kabutz Poznejte své limity Greg Colvin Poznejte, kdy dokončíte práci Dan Bergh Johnsson Rozsáhlá vzájemně propojená data patří do databáze Diomidis Spinellis Naučte se cizí jazyky Klaus Marquardt Naučte se odhadovat Giovanni Asproni Naučte se říct: Ahoj, světe Thomas Guest Nechte projekt mluvit sám za sebe Daniel Lindner Linker není žádným magickým programem Walter Bright Dlouhověkost provizorních řešení Klaus Marquardt Rozhraní by se měla snadno používat správným způsobem a těžko špatným Scott Meyers Ať se neviditelné stane více viditelným Jon Jagger 6 97 klíčových znalostí programátora

10 Předávání zpráv vede v paralelních systémech k lepší rozšiřitelnosti Russel Winder Odkaz budoucnosti Linda Rising Nevyužité příležitosti k polymorfizmu Kirk Pepperdine Novinka: Testeři jsou vaši kamarádi Burk Hufnagel Pouze jeden binární soubor Steve Freeman Pouze kód říká pravdu Peter Sommerlad Nezapomínejte na sestavení Steve Berczuk Párové programování Gudny Hauknes, Kari Røssland a Ann Katrin Gagnat Preferujte typy specifické pro doménu před primitivními typy Einar Landre Předcházejte chybám Giles Colborne Profesionální programátor Robert C. Martin (Uncle Bob) Všechno verzujte Diomidis Spinellis Odložte myš a odstupte od klávesnice Burk Hufnagel Čtěte kód Karianne Berg Zajímejte se o humanitní vědy Keith Braithwaite Obsah 7

11 Často znovu vynalézejte kolo Jason P. Sage Odolejte pokušení návrhového vzoru jedináček Sam Saariste Honbu za výkonem komplikuje špinavý kód Kirk Pepperdine Jednoduchost jde ruku v ruce s redukcí Paul W. Homer Princip jedné odpovědnosti Robert C. Martin (Uncle Bob) Začněte u Ano Alex Miller Odstupte a automatizujte, automatizujte, automatizujte Cay Horstmann Využijte nástrojů pro analýzu kódu Sarah Mount Testujte požadované, nikoli nahodilé chování Kevlin Henney Testujte přesně a konkrétně Kevlin Henney Testujte ve spánku (a přes víkendy) Rajith Attapattu Testování je přísností softwarového vývoje Neal Ford Myšlení ve stavech Niclas Nilsson Dvě hlavy jsou často lepší než jedna Adrian Wible Dvakrát špatně může znamenat dobře (a těžko se opravuje) Allan Kelly Ubuntu pro vaše přátele Aslam Khan 8 97 klíčových znalostí programátora

12 Unixové nástroje jsou vaši kamarádi Diomidis Spinellis Použijte správný algoritmus a datovou strukturu Jan Christiaan JC van Winkel Přehnané protokolování vám na klidném spánku nepřidá Johannes Brodwall WET pomáhá překonat výkonnostní překážky Kirk Pepperdine Když programátoři a testeři spolupracují Janet Gregory Piště kód tak, jako byste museli zajišťovat jeho podporu po zbytek svého života Yuriy Zubarev Vytvářejte malé funkce na základě příkladů Keith Braithwaite Vytvářejte testy pro lidi Gerard Meszaros O kód se musíte starat Pete Goodliffe Vaši zákazníci neuvažují nad tím, co říkají Nate Jackson Přispěvatelé Rejstřík Obsah 9

13

14 Tipy podle zaměření Chyby a opravy Než začnete obviňovat ostatní, zkontrolujte vlastní kód Nedotýkej se toho kódu Použití systému pro sledování chyb Dvakrát špatně může znamenat dobře (a těžko se opravuje) Vývoj Nasazujte brzy a často Nedotýkej se toho kódu Nainstaluj si mě Udržujte build čistý Nechte projekt mluvit sám za sebe Pouze jeden binární soubor Nezapomínejte na sestavení Vzhled kódu Automatizujte své kódovací standardy Na odsazení kódu záleží Revize kódu Pár slov ke komentářům Komentujte pouze to, co kód sám nedokáže říct Využijte nástrojů pro analýzu kódu Tipy podle zaměření 11

15 Techniky návrhu Aplikujte principy funkcionálního programování Položte si otázku: Co by udělal uživatel? (vy jím nejste) V jednoduchosti je krása Nástroje volte s rozvahou Programujte v jazyce domény Kód představuje návrh Odůvodnění správnosti kódu Pohodlnost nepatří mezi ctnosti Rozlište technické a business výjimky Neopakujte se Zapouzdřete chování, ne pouze stav Zlaté pravidlo návrhu API Komunikace mezi procesy ovlivňuje reakční dobu aplikace Rozhraní by se měla snadno používat správným způsobem a těžko špatným Předávání zpráv vede v paralelních systémech k lepší rozšiřitelnosti Nevyužité příležitosti k polymorfismu Pouze kód říká pravdu Preferujte typy specifické pro doménu před primitivními typy Předcházejte chybám Odolejte pokušení návrhového vzoru jedináček Princip jedné odpovědnosti Myšlení ve stavech WET pomáhá překonat výkonnostní překážky Myšlení v souvislostech Programujte v jazyce domény Jazyky specifické pro doménu Naučte se cizí jazyky Preferujte typy specifické pro doménu před primitivními typy Zajímejte se o humanitní vědy Myšlení ve stavech Vytvářejte malé funkce na základě příkladů klíčových znalostí programátora

16 Chyby, výjimky a ladění Rozlište technické a business výjimky Neignorujte chyby Nesnažte se svůj program přibít do vzpřímené polohy Předcházejte chybám Přehnané protokolování vám na klidném spánku nepřidá Výuka a dovednosti Nepřetržité učení Procvičujte se Nestačí pouze naučit se jazyk, ale porozumět jeho kultuře Naplňte své ambice pomocí open-source Mýtus guru Dřina se nevyplácí Čtěte kód Zajímejte se o humanitní vědy Často znovu vynalézejte kolo Tajemno a magično Nevěřte na kouzla Nedotýkej se toho kódu Mýtus guru Naučte se používat nástroje příkazového řádku Linker není žádným magickým programem Testujte ve spánku (a přes víkendy) Přehnané protokolování vám na klidném spánku nepřidá Piště kód tak, jako byste museli zajišťovat jeho podporu po zbytek svého života Výkon a optimalizace Aplikujte principy funkcionálního programování Čísla s plovoucí řádovou čárkou nejsou reálná Vylepšete kód tím, že ho odstraníte Komunikace mezi procesy ovlivňuje reakční dobu aplikace Poznejte své limity Tipy podle zaměření 13

17 Rozsáhlá vzájemně propojená data patří do databáze Předávání zpráv vede v paralelních systémech k lepší rozšiřitelnosti Honbu za výkonem komplikuje špinavý kód Použijte správný algoritmus a datovou strukturu WET pomáhá překonat výkonnostní překážky Profesionální přístup Nepřetržité učení Procvičujte se Dřina se nevyplácí Dlouhověkost provizorních řešení Profesionální programátor Odložte myš a odstupte od klávesnice Testování je přísností softwarového vývoje Piště kód tak, jako byste museli zajišťovat jeho podporu po zbytek svého života O kód se musíte starat Programovací jazyky a paradigmata Aplikujte principy funkcionálního programování Jazyky specifické pro doménu Nestačí pouze naučit se jazyk, ale porozumět jeho kultuře Ovládejte více než dva programovací jazyky Naučte se cizí jazyky Refaktorování a údržba kódu Jednejte s opatrností Před refaktorováním Skautské pravidlo Komentujte pouze to, co kód sám nedokáže říct Nebojte se, že něco rozbijete Vylepšete kód tím, že ho odstraníte Udržujte build čistý Poznejte, kdy dokončíte práci Dlouhověkost provizorních řešení Odkaz budoucnosti klíčových znalostí programátora

18 Pouze kód říká pravdu Nezapomínejte na sestavení Profesionální programátor Honbu za výkonem komplikuje špinavý kód Jednoduchost jde ruku v ruce s redukcí Ubuntu pro vaše přátele O kód se musíte starat Znovupoužití verzus opakování Pozor na sdílený kód Pohodlnost nepatří mezi ctnosti Procvičujte se Neopakujte se Často znovu vynalézejte kolo Použijte správný algoritmus a datovou strukturu WET pomáhá překonat výkonnostní překážky Plány, termíny a odhady Jednejte s opatrností Kód představuje návrh Poznejte, kdy dokončíte práci Naučte se odhadovat Ať se neviditelné stane více viditelným Jednoduchost V jednoduchosti je krása Naučte se říct: Ahoj světe Odkaz budoucnosti Jednoduchost jde ruku v ruce s redukcí Práce v týmu Revize kódu Naučte se cizí jazyky Párové programování Začněte u Ano Tipy podle zaměření 15

19 Dvě hlavy jsou často lepší než jedna Ubuntu pro vaše přátele Když programátoři a testeři spolupracují Testy, testování a testeři Aplikujte principy funkcionálního programování Kód představuje návrh Nesnažte se okouzlit testovacími daty Zlaté pravidlo návrhu API Rozhraní by se měla snadno používat správným způsobem a těžko špatným Ať se neviditelné stane více viditelným Novinka: Testeři jsou vaši kamarádi Testujte požadované, nikoli nahodilé chování Testujte přesně a konkrétně Testujte ve spánku (a přes víkendy) Testování je přísností softwarového vývoje Když programátoři a testeři spolupracují Vytvářejte malé funkce na základě příkladů Vytvářejte testy pro lidi klíčových znalostí programátora

20 Úvod I ten nejnovější počítač pouze znásobuje pradávný problém vztahu mezi lidskými bytostmi a na konci bude zprostředkovatel muset čelit problému toho, co říci a jak. Edward R. Murrow V hlavách programátorů se honí mnoho myšlenek. Programovací jazyky, programovací techniky, vývojová prostředí, způsoby kódování, nástroje, proces vývoje, termíny, schůzky, softwarová architektura, návrhové vzory, dynamika týmu, kód, požadavky, chyby, kvalita kódu a mnoho a mnoho dalšího. Programování je umění, dovednost a věda, zdaleka přesahující rámec samotného programu. Programování spojuje diskrétní svět počítačů s fluidním světem lidských záležitostí. Programátoři jsou prostředníky mezi vyjednanými a nejistými obchodními fakty a neústupnou oblastí bitů a bajtů a vyšších jazykových konstruktů. Vzhledem k množství potřebných znalostí a bezpočtu možných postupů nemůže nikdo označovat právě svůj postup za ten jediný správný. Kniha 97 klíčových znalostí programátora staví na kolektivních vědomostech a zkušenostech a spíše než ucelený větší obrázek poskytuje představu odborné veřejnosti o tom, co by měl každý programátor znát. Svým rozsahem tak pokrývá vše od rad týkajících se kódu po vzdělávání, od použití algoritmů po agilní uvažování, od implementačního know-how po profesionalismus, od způsobu k podstatě. Příspěvky na sebe vzájemně nenavazují a není to ani záměr spíše opak je pravdou. Hodnota příspěvků pramení právě z jejich osobitosti. Hodnota kolekce spočívá v tom, jak se vzájemně doplňují, potvrzují, nebo jsou dokonce v rozporu. Nenajdete zde žádné oslí můstky je na vás reagovat, uvážit a spojit si dohromady, co čtete, vzít v potaz váš vlastní kontext a zkušenosti. Oprávnění Autorskou ochranu každého článku lze přirovnat k open-source řešením. Každý tip je dostupný online a chráněn na základě licence Creative Commons, což znamená, že můžete každý z článků samostatně využívat ve své praxi, pokud uvedete jeho autora. Úvod 17

21 Poděkování Mnoho lidí přispělo svým časem či názory ke vzniku knihy 97 klíčových znalostí programátora, a to přímo i nepřímo. Ti všichni si zaslouží uznání. Richard Monson-Haefel je původce myšlenky edice 97 klíčových znalostí a také sestavil první knihu této série 97 klíčových znalostí softwarového architekta, do které jsem přispěl. Chtěl bych Richardovi poděkovat za tuto sérii, její koncept otevřeného přispívání a hlavně za podporu mého nápadu realizovat tuto knihu. Chci poděkovat všem, kteří věnovali čas a úsilí přispět do tohoto projektu. Přispěvatelům, kteří jsou se svými radami uvedeni v této knize, i těm, kteří vybráni nebyli. Velký objem a kvalita příspěvků učinily výběr hodně složitým, pevně daný počet bohužel vyřadil i několik těch, které by se normálně do knihy podařilo vmáčknout. Velký dík za zpětnou vazbu, komentáře a další nápady patří Giovanni Aspronimu, Paulu Colin Glosterovi a Michaelu Hungerovi. Děkuji O Reilly za podporu, kterou věnovalo tomuto projektu, velkou pozornost a lidem v O Reilly jmenovitě pak Miku Loukidesovi, Laurelu Ackermanovi, Ediemu Freedmanovi, Edu Stephensonovi a Rachel Monaghanové. Chtěl bych také poděkovat svojí ženě Carolyn za to, že vnesla pořádek do mého chaosu, a také mým dvěma synům, Stefanovi a Yannickovi za znovuvytvoření části chaosu. Doufám, že kniha vám poskytne informace, vhled a inspiraci. Poznámka redakce českého vydání Nakladatelství Computer Press, které pro vás tuto knihu přeložilo, stojí o zpětnou vazbu a bude na vaše podněty a dotazy reagovat. Můžete se obrátit na následující adresy: Computer Press redakce PC literatury Holandská Brno nebo knihy@cpress.cz Další informace a případné opravy českého vydání knihy najdete na internetové adrese Prostřednictvím uvedené adresy můžete též naší redakci zaslat komentář nebo dotaz týkající se knihy. Na vaše reakce se srdečně těšíme klíčových znalostí programátora

22

23 Jednejte s opatrností Seb Rose Ať už se ujmete čehokoli, jednejte s opatrností a uvažte následky. Anon Bez ohledu na to, jak příjemně vypadá plán na začátku iterace, alespoň část tohoto času nevyhnutelně budete pod tlakem. Pokud se dostanete od situace, kdy se musíte rozhodnout mezi tím, jestli to udělat správně, anebo rychle, je často lákavé to udělat rychle s vědomím toho, že se později budete muset vrátit a opravit to. Pokud učiníte toto předsevzetí, musíte si za ním stát sami před sebou, před svým týmem i zákazníkem. Velmi často však další iterace přinese nové problémy vyžadující vaši pozornost. Tento druh odložené práce se často označuje jako technický dluh a dozajista není vaším přítelem. Martin Fowler to ve svém rozboru technických dluhů ( TechnicalDebtQuadrant.html) označuje za záměrný technický dluh a neměl by se zaměňovat s neúmyslným technickým dluhem. Technický dluh je jako půjčka v krátkodobém horizontu z ní těžíte, ale budete z ní muset odvádět úroky, dokud nebude úplně splacená. Zkratky použité v kódu ztěžují přidávání nových funkcí a refactoring kódu. Jsou úrodnou půdou pro defekty a křehké testy. Čím déle je necháte bez povšimnutí, tím horší to bude. V okamžiku, kdy se dostanete k původní opravě, může existovat již celá řada ne příliš dokonalých rozhodnutí učiněných na základě původního problému, což značně ztěžuje opravu kódu a jeho refaktorování. Často se k opravě původního problému přikročí až v okamžiku, kdy se situace natolik zhorší, že je oprava původního problému nutná. A v tento okamžik je oprava často natolik obtížná, že si nemůžete potřebný čas nebo riziko s ní spojené dovolit klíčových znalostí programátora

24 Nastanou případy, kdy se uchýlíte k technickému dluhu, abyste stihli termín nebo v minimálním rozsahu implementovali funkci. Pokuste se těmto situacím vyhnout. Pokud to však okolnosti vyžadují a není zbytí, nezbývá než se vydat touto cestou. Nezapomeňte však svůj technický dluh sledovat a rychle ho splatit, jinak půjdou věci rychle z kopce. Hned jak učiníte takovýto kompromis, udělejte si do bloku poznámku anebo tuto skutečnost poznamenejte ve svém systému pro sledování problémů, abyste zajistili, že se na něj nezapomene. Pokud naplánujete splacení dluhu v další iteraci, bude cena minimální. Pokud dluh zůstane nesplacený, zvýší se úroky. Ty je třeba sledovat a mít náklady na očích. Zdůrazní se tak dopad technického dluhu na obchodní hodnotu projektu a dosáhne se potřebného upřednostnění jeho splacení. Způsob jakým vypočítat a sledovat úroky bude záviset na konkrétním projektu, sledování je však nezbytné. Splaťte technické dluhy tak rychle, jak je to jen možné. Nebylo by moudré to neudělat. Zkušenosti expertů z praxe 21

25 Aplikujte principy funkcionálního programování Edward Garson Funkcionální programování se těší nové vlně zájmu ze strany mainstreamové programátorské komunity. Z části je to proto, že vynořující se vlastnosti funkcionálního paradigmatu vhodně adresují výzvy, kterým čelíme v důsledku přechodu průmyslu na vícejádrovou architekturu. Přestože je to jistě důležité využití, není to důvod proč vás tento příspěvek nabádá ke znalosti funkcionálního programování. Ovládnutí funkcionálního paradigmatu může významně zlepšit kvalitu kódu, který v jiných kontextech vytváříte. Pokud hluboce rozumíte funkcionálnímu paradigmatu a aplikujete ho, budou vaše návrhy vykazovat mnohem vyšší stupeň referenční transparence. Referenční transparence je velmi žádoucí vlastností značící, že funkce konzistentně vrací pro stejné vstupy stejné výsledky, bez ohledu na to, odkud a kdy se volají. To znamená, že vyhodnocení funkce závisí méně, ideálně vůbec, na vedlejších efektech stavových změn. Hlavní příčinou problémů v imperativním kódu jsou nestálé proměnné. Všichni, kteří tyto řádky čtou, už jistě pátrali po příčině toho, proč nemá určitá proměnná v dané situaci takovou hodnotu, jaká se očekává. Viditelná sémantika může pomoci zmírnit tyto zákeřné defekty anebo přinejmenším drasticky snížit počet míst, kde se vyskytují. Hlavním pachatelem je však neprozřetelnost návrhů, které podporují nadměrnou proměnlivost. V tomto ohledu se od průmyslu nedočkáme žádné výrazné podpory. Úvody do problematiky objektově orientovaného programování mlčky podporují takovéto návrhy, protože často ukazují příklady relativně dlouhověkých objektů, jež zvesela vzájemně volají své editační a potencionálně nebezpečné metody. V případě použití rafinovaného návrhu řízeného testy, především pak dodržujícího zásadu simulovat role, a nikoli objekty ( je možné nežádoucí proměnlivost odstranit klíčových znalostí programátora

26 Výsledkem je návrh, který má lepší rozdělení odpovědností mezi více menších funkcí pracujících s jim předanými parametry namísto s nestálými členskými proměnnými. Vyskytne se menší množství defektů a často se také snadněji budou ladit, protože je v případě těchto návrhů jednodušší určit, kde se konkrétní hodnota mění, než je tomu v návrzích, kdy je třeba dovodit konkrétní kontext, jež má za následek chybné přiřazení. To podstatně zvyšuje stupeň referenční transparentnosti. Nic jiného vám tyto myšlenky nevryje do paměti tak, jako funkcionální programovací jazyk, kde je tento výpočetní model normou. Tento přístup samozřejmě není za všech okolností optimální. Např. v objektově orientovaných systémech tento způsob často podává lepší výsledky při vývoji modelu domény (kde vzájemná spolupráce slouží k redukci složitosti business rolí) než při vývoji uživatelského rozhraní. Osvojte si funkcionální paradigma, abyste mohli v ostatních doménách uváženě aplikovat nabyté vědomosti. Vaše objektové systémy budou dosahovat vyššího stupně referenční transparentnosti a budou se svým funkcionálním protějškům podobat mnohem více, než si myslíte. V některých případech se dokonce bude zdát, že je (na nejvyšší úrovni) funkcionální a objektově orientované programování pouze vzájemným odrazem tvořícím počítačovou obdobu yin a yang. Zkušenosti expertů z praxe 23

27 Položte si otázku: Co by udělal uživatel? (vy jím nejste) Giles Colborne Všichni máme ve zvyku předpokládat, že ostatní lidé myslí jako my. Ale nemyslí. Psychologové to označují za falešný konsenzus. Když lidé myslí nebo jednají jinak než my, s velkou pravděpodobností je (podvědomě) označíme za podivíny. To vysvětluje, proč je pro programátory tak obtížné vžít se do role uživatelů. Uživatelé nemyslí jako programátoři. Pro začátek tráví u počítače mnohem méně času. Neví, jak počítač pracuje a ani je to nezajímá. To znamená, že nemohou čerpat z artilerie programátorům tak dobře známých technik pro řešení problémů. Neznají návrhové vzory a výsledky práce programátorů používají skrze rozhraní. Nejlepším způsobem, jak zjistit, jak uživatel uvažuje, je pozorovat ho. Požádejte uživatele, aby provedl určitý úkol s pomocí softwaru podobajícího se tomu, který vyvíjíte. Ujistěte se, že je tento úkol realistický Sečti hodnoty ve sloupci je v pořádku, Vypočítej své výdaje za poslední měsíc je ještě lepší. Vyhněte se příliš specifickým úkolům jako je Mohl bys označit tyto buňky tabulky a pod ně uvést jejich sumu?. Tento požadavek už sám o sobě k něčemu nabádá. Nechte za uživatele hovořit jeho vlastní postup. Nepřerušujte ho. Nesnažte se mu pomoci. Položte si otázku, proč dělá právě to, a ne tohle. První věcí, které si všimnete, je, že uživatelé dělají mnohé základní věcí podobně. Pokouší se plnit úkoly ve stejném pořadí a dělají stejné chyby na stejných místech. Na těchto základních věcech byste měli stavět. Velmi se to liší od návrhářských schůzek, kde lidé poslouchají diskuze na téma Co když chce uživatel klíčových znalostí programátora

28 Vede to ke komplikovaným funkcím a nejasnostem v tom, co uživatelé chtějí. Sledování uživatelů tyto nejasnosti rozptýlí. Uvidíte, jak se uživatelé při něčem zaseknou. Když se zaseknete vy, rozhlédnete se okolo. Když se zaseknou uživatelé, svůj pohled na věc zúží. Je pro ně obtížnější vidět řešení jinde na obrazovce. To je jeden z důvodů, proč je textová nápověda chabým řešením nevhodného návrhu uživatelského rozhraní. Pokud jsou instrukce nebo nápověda nezbytné, umístěte ji hned vedle problematických oblastí. Úzké zaměření pohledu uživatele je důvod, proč jsou tzv. tool-tipy úspěšnější než klasická nápověda. Uživatelé mají ve zvyku dělat zmatek. Najdou řešení, které funguje, a zůstanou u něj, bez ohledu na to, jak složité je. Je lepší poskytnout jeden skutečně zjevný způsob, jak úkol provést, než dvě nebo tři zkratky. Zjistíte také, že existuje rozdíl v tom, co uživatelé říkají, že chtějí, a co ve skutečnosti dělají. To je znepokojivé, protože se požadavky uživatelů běžně získávají dotázáním se uživatelů. Proto je nejlepším způsobem, jak určit požadavky, sledovat uživatele. Hodinové sledování uživatelů přinese více informací než den strávený odhadováním toho, co chtějí. Zkušenosti expertů z praxe 25

29 Automatizujte své kódovací standardy Filip van Laenen Pravděpodobně jste tam také byli. Na začátku projektu má každý mnoho dobrých nápadů nazývejme je předsevzetí nového projektu. Poměrně často jsou mnohá z těchto předsevzetí zaznamenaná v dokumentech. Ty, které se týkají kódu, skončí v kódovacích standardech projektu. V průběhu úvodní schůzky hlavní vývojář projde dokumenty a v nejlepším případě se všichni shodnou na tom, že se pokusí podle nich postupovat. Poté co se však projekt rozběhne, se tyto dobré úmysly jeden po druhém rozplynou jako pára nad hrncem. Po dokončení projektu vypadá kód naprosto chaoticky a nikdo nechápe, jak k tomu mohlo dojít. Kdy se věci zvrtly? Pravděpodobně už na úvodní schůzce. Někteří z účastníků projektu nedávali pozor. Jiní požadavku nerozuměli, či ještě hůře nesouhlasili a už plánovali svou rebelii v oblasti standardu kódování. Někteří sice požadavek akceptovali a souhlasili s ním, ale jak se tlak v průběhu projektu zvyšoval, museli od něj upustit. Vhodně formátovaný kód zákazníka požadujícího větší funkcionalitu zajímat nebude. Dodržování standardů kódování navíc může být vcelku nudnou záležitostí, pokud se neautomatizuje. Jen si zkuste ručně odsadit kód zaneřáděné třídy. Pokud je to ale takový problém, proč bychom vůbec měli chtít kódovací standard? Jedním z důvodů formátování kódu jednotným způsobem je, že si nikdo nemůže přivlastnit určitou část kódu pouze tím, že ho naformátuje svým vlastním způsobem. Můžeme chtít zabránit vývojářům v tom, aby používali určité antivzory, a vyhnout se tak běžným chybám. Standard kódování by měl konec konců usnadnit práci na projektu a udržovat rychlost vývoje od začátku až do konce. Z toho jasně plyne, že by všichni měli souhlasit s použitým standardem kódování ničemu nepomůže, pokud jeden vývojář používá pro odsazení kódu tři mezery, zatímco jiný čtyři klíčových znalostí programátora

30 Existuje celá řada nástrojů, které generují hlášení o kvalitě kódu a je možné je použít k dokumentaci a údržbě standardu kódování, to však jako řešení nestačí. Standard by se měl automatizovat, a je-li to možné, i vynutit. Zde je několik příkladů: Ujistěte se, že je formátování kódu součástí procesu sestavení, takže se automaticky provede pokaždé, když někdo provádí překlad svého kódu. Používejte nástroje pro statickou analýzu kódu, které v kódu vyhledají nežádoucí anti-vzory. Pokud se nějaké najdou, přeruší se sestavení. Naučte se tyto nástroje nakonfigurovat tak, abyste mohli hledat své vlastní anti-vzory specifické pro váš projekt. Neměřte pouze pokrytí testů, ale také automaticky kontrolujte jejich výsledky. Přerušte sestavení, pokud je pokrytí testů příliš malé. Pokuste se tyto postupy aplikovat na všechno, co považujete za důležité. Nebudete moci automatizovat vše, na čem vám skutečně záleží. V případě věcí, které nemůžete automaticky označit nebo opravit, uvažte sadu pravidel doplňujících automatizovaný standard kódování, akceptujte však skutečnost, že je vy a vaši kolegové nemusí tak pečlivě dodržovat. Standard kódování by měl být dynamický, a nikoli statický. Jak se projekt vyvíjí, jeho potřeby se mění a to, co se zdálo chytré na začátku, o několik měsíců později už tak chytré být nemusí. Zkušenosti expertů z praxe 27

31 V jednoduchosti je krása Jørn Ølmheim Jeden z výroků řeckého filozofa Platona by podle mého měli softwarový vývojáři dobře znát a mít ho neustále na paměti: Krása návrhu a harmonie a elegance a dobrý rytmus závisí na jednoduchosti. Tato jedna věta shrnuje hodnoty, o které bychom měli coby softwaroví vývojáři usilovat. Existuje řada vlastností, které jsou u kódu žádoucí: Čitelnost Udržovatelnost Rychlost vývoje Neuchopitelná kvalita krásy Platon nám říká, že faktorem, umožňujícím všechny tyto čtyři kvality, je jednoduchost. Co je to krásný kód? To je potencionálně velmi subjektivní otázka. Vnímání krásy závisí převážně na daném zázemí, stejně jako naše vnímání čehokoli závisí na našem zázemí. Lidé vzdělaní v oblasti umění jinak vnímají (anebo k ní alespoň jinak přistupují) krásu než lidé vzdělaní ve vědních oborech. Studenti umění mají tendenci přistupovat ke kráse softwaru tak, že software porovnávají s uměleckými díly. Naproti tomu studenti vědních oborů zpravidla hovoří o symetrii a zlatém řezu ve snaze redukovat věci na vzorce. Podle mých zkušeností je jednoduchost základem většiny argumentů obou stran klíčových znalostí programátora

32 Zamyslete se nad zdrojovým kódem, který jste studovali. Pokud jste nestrávili nějaký čas studováním kódu jiných lidí, odložte tuto knihu a najděte si nějaký open-source ke studiu. Myslím to vážně. Najděte na Webu nějaký kód ve vámi požadovaném programovacím jazyce, napsaném nějakým uznávaným a dobře známým expertem. Jste zpátky? Dobře. Tak kde jsme to skončili? Ano, už vím přisel jsem na to, že kódy, které považuji za krásné a jsem s nimi takříkajíc na stejné vlně, mají něco společného. Tím hlavním je jednoduchost. Přišel jsem na to, že bez ohledu na to, jak komplexní celá aplikace nebo systém je, jednotlivé části musí být jednoduchými objekty s jednou zodpovědností obsahující podobně jednoduché, vyhraněné metody s popisnými názvy. Někteří lidé považují krátké metody o rozsahu 5 až 10 řádků kódu za extrém a v některých jazycích je toho velmi obtížné docílit, přesto si myslím, že je takováto stručnost žádoucím cílem. Ponaučením, které byste si měli odnést, je, že krásný kód je jednoduchý kód. Každá jednotlivá část se udržuje jednoduchá s jednoduchými odpovědnostmi a jednoduchými vztahy s ostatními částmi systému. To je způsob, jakým můžeme systémy v průběhu času udržet upravovatelné, s čistým, jednoduchým, testovatelným kódem a zajistit vysokou rychlost vývoje v průběhu života systému. Krása je v jednoduchosti. Zkušenosti expertů z praxe 29

33 Pokud se Vám tato ukázka knihy líbila, bude úžasné, když nás, všechny spolutvůrce, podpoříte zakoupením jedné kopie na matora. Kniha nestojí víc než večeře (pro jednoho) v restauraci. Tento text vznikl díky práci následujících lidí: 1) autora, který sepsal svoje jedinečné myšlenky 2) překladatele, který je pečlivě přeložil (neplatí u českých titulů :) 3) redaktora, který dohlížel na srozumitelnost a kvalitu textu 4) korektora, který ochránil vaše oči před hrubkami a překlepy 5) grafika, který připravil obálku (nebo grafiku v textu) 6) sazeče, který knihu vysázel do této podoby Všichni vám děkujeme..