Kevlin Henney. 97 klíčových znalostí programátora

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

97 klíčových znalostí programátora Kevlin Henney Computer Press, a. s., 2010. 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 9780596809485 2010, 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., 2010. Computer Press, a. s., Holandská 3, 639 00 Brno Objednávky knih: http://knihy.cpress.cz distribuce@cpress.cz tel.: 800 555 513 ISBN 978-80-251-3145-9 Prodejní kód: K1834 Vydalo nakladatelství Computer Press, a. s., jako svou 3645. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Ú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

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á 8 639 00 Brno nebo knihy@cpress.cz Další informace a případné opravy českého vydání knihy najdete na internetové adrese http://knihy.cpress.cz/k1834. 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. 18 97 klíčových znalostí programátora

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ů (http://martinfowler.com/bliki/ 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. 20 97 klíčových znalostí programátora

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

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 (http://www.jmock.org/oopsla2004.pdf), je možné nežádoucí proměnlivost odstranit. 22 97 klíčových znalostí programátora

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

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. 24 97 klíčových znalostí programátora

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

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. 26 97 klíčových znalostí programátora

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

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. 28 97 klíčových znalostí programátora

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