Richard Monson-Haefel. 97 klíčových znalostí softwarového architekta

Richard Monson-Haefel 97 klíčových znalostí softwarového architekta Computer Press, a. s. Brno 2010

97 klíčových znalostí softwarového architekta Richard Monson-Haefel Computer Press, a. s., 2010. Vydání první. Jazyková korektura: Jana Otevřelová 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, Zuzana Šindlerová, Dagmar Hajdajová Odpovědný redaktor: Martin Herodek Technický redaktor: Jiří Matoušek Produkce: Petr Baláš Computer Press, a.s. 2010. Authorized Czech translation of 97 Things Every Software Architect Should Know ISBN 9780596522698 2009, O Reilly Media, Inc. 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 Software Architect Should Know. Originální copyright: 2009 O Reilly Media, Inc. 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-3313-2 Prodejní kód: K1806 Vydalo nakladatelství Computer Press, a. s., jako svou 3711. 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 Předmluva....................................................... 11 Požadavky mají přednost před vaším životopisem................. 14 Nitin Borwankar Zabraňte esenciální složitosti, odstraňte nahodilou složitost....... 16 Neal Ford Váš největší problém pravděpodobně nebude technického rázu... 18 Mark Ramm Komunikace je král, srozumitelnost a vedení jeho oddanými služebníky....................................................... 20 Mark Richards Architektura aplikace určuje její výkon............................ 22 Randy Stafford Hledejte hodnotu v požadovaných vlastnostech.................. 24 Einar Landre Vstaňte.......................................................... 26 Udi Dahan Všechno nakonec selže........................................... 28 Michael Nygard Vyjednáváte častěji, než si myslíte................................ 30 Michael Nygard Kvantifikujte..................................................... 32 Keith Braithwaite Jeden řádek funkčního kódu odpovídá 500 řádků specifikace..... 34 Allison Randal Obsah 3

Neexistuje žádné univerzální řešení............................... 36 Randy Stafford Nikdy není dost brzy začít přemýšlet nad výkonem................ 38 Rebecca Parsons Architektura je o rovnováze...................................... 40 Randy Stafford Utéct z místa činu je zločin....................................... 42 Niclas Nilsson Může být víc než jeden........................................... 44 Keith Braithwaite Byznys určuje směr............................................... 46 Dave Muirhead Jednoduchost před obecností, použití před znovupoužitím....... 48 Kevlin Henney Architekti musí mít zkušenosti.................................... 50 John Davies Průběžně integrujte.............................................. 52 David Bartlett Vyhněte se plánům vedoucím k selhání........................... 54 Norman Carnovale Kompromisy v architektuře....................................... 56 Mark Richards Databáze jako pevnost........................................... 58 Dan Chak Řiďte se nejistotou............................................... 60 Kevlin Henney Varování: Problémy v zrcadle mohou být větší, než se zdá......... 62 Dave Quick Opětovné použití je o lidech a vzdělání, ne jenom o architektuře.. 64 Jeremy Meyer V oblasti architektury není žádné já............................. 66 Dave Quick 4 97 klíčových znalostí softwarového architekta

Získejte pohled ze 300 metrů..................................... 68 Erik Doernenburg Vyzkoušejte a pak vybírejte....................................... 70 Erik Doernenburg Pochopte byznys doménu........................................ 72 Mark Richards Programování je akt návrhu...................................... 74 Einar Landre Dejte vývojářům autonomii...................................... 76 Philip Nelson Čas všechno mění................................................ 78 Philip Nelson Softwarový architekt se píše s malým a, smiřte se s tím........... 80 Barry Hawkins Rozsah je nepřítelem úspěchu.................................... 82 Dave Quick Važte si dohledu více než showmanství........................... 84 Barry Hawkins Softwarová architektura má etické následky...................... 86 Michael Nygard Mrakodrapy nejsou škálovatelné................................. 88 Michael Nygard Heterogenita vítězí............................................... 90 Edward Garson Všechno se točí okolo výkonu.................................... 92 Craig Russell Doplňte si prázdná místa......................................... 94 Michael Nygard Mluvit a jednat................................................... 96 Mark Richards Kontext je králem................................................ 98 Edward Garson Obsah 5

Trpaslíci, elfové, čarodějové a králové............................ 100 Evan Cofsky Poučte se od architektů budov.................................. 102 Keith Braithwaite Bojujte proti opakování......................................... 104 Niclas Nilsson Vítejte ve skutečném světě...................................... 106 Gregor Hohpe Neřiďte, pozorujte.............................................. 108 Gregor Hohpe Architekt Janus................................................. 110 David Bartlett Předmětem zájmu architekta jsou hranice a rozhraní............. 112 Einar Landre Podpořte vývojáře.............................................. 114 Timothy High Zaznamenávejte si svá odůvodnění.............................. 116 Timothy High Pochybujte o předpokladech obzvláště o svých vlastních....... 118 Timothy High Sdílejte své znalosti a zkušenosti................................ 120 Paul W. Homer Nemoc ze vzorů................................................. 122 Chad La Vigne V architektuře není místo pro metafory.......................... 124 David Ing Zaměřte se na podporu a údržbu aplikace....................... 126 Mncedisi Kasper Připravte se vybrat dvě vlastnosti................................ 128 Bill de hóra Preferujte principy, axiomy a analogie před možnostmi a chutí... 130 Michael Harmer 6 97 klíčových znalostí softwarového architekta

Začněte u chodící kostry........................................ 132 Clint Shank Všechno se točí okolo dat....................................... 134 Paul W. Homer Ujistěte se, že jsou jednoduché věci skutečně jednoduché........ 136 Chad La Vigne Architekt je v prvé řadě vývojář.................................. 138 Mike Brown Hodnota ROI.................................................... 140 George Malamidis Váš systém je zastaralý, zohledněte návrh........................ 142 Dave Anderson Pokud máte jen jedno řešení, obstarejte si druhý názor........... 144 Timothy High Pochopte důsledky změn....................................... 146 Doug Crawford Musíte rozumět také hardwaru.................................. 148 Kamal Wickramanayake Nynější zkratky................................................. 150 Scot Mcphee Perfektní je nepřítelem dost dobrého............................ 152 Greg Nyberg Vyhněte se dobrým nápadům.................................. 154 Greg Nyberg Skvělý obsah tvoří skvělé systémy............................... 156 Zubin Wadia Společnost vs. rozezlený architekt............................... 158 Chad La Vigne Roztáhněte řešení do stran, abyste viděli, kde praskne............ 160 Stephen Jones Pokud to navrhnete, měli byste být schopni to také naprogramovat....162 Mike Brown Obsah 7

Z květáku se nestane růže, ať už ho nazvete jakkoli.............. 164 Sam Gardiner Stálé problémy mají kvalitní řešení............................... 166 Sam Gardiner Chce to píli..................................................... 168 Brian Hart Přijměte zodpovědnost za svá rozhodnutí....................... 170 Yi Zhou Nesnažte se být chytří........................................... 172 Eben Hewitt Pečlivě si vyberte zbraně, odkládejte je s rozvahou............... 174 Chad La Vigne Váš zákazník není vaším zákazníkem............................. 176 Eben Hewitt Nikdy to tak nebude vypadat.................................... 178 Peter Gillard-Moss Zvolte frameworky, které spolupracují s ostatními................ 180 Eric Hawthorne Vytvořte funkční obchodní model............................... 182 Yi Zhou Řiďte i data, nejenom kód....................................... 184 Chad La Vigne Splaťte svůj technický dluh...................................... 186 Burkhardt Hufnagel Nebuďte řešitelem problému.................................... 188 Eben Hewitt Vytvářejte systémy tak, aby byly zuhanden..................... 190 Keith Braithwaite Najděte a važte si nadšených řešitelů problémů.................. 192 Chad La Vigne 8 97 klíčových znalostí softwarového architekta

Software ve skutečnosti neexistuje.............................. 194 Chad La Vigne Naučte se nový jazyk............................................ 196 Burkhardt Hufnagel Vaše řešení nemůže zohledňovat budoucnost................... 198 Richard Monson-Haefel Problém s přijetím ze strany uživatelů............................ 200 Norman Carnovale Význam consommé............................................. 202 Eben Hewitt Rozhraní je pro koncové uživatele systémem..................... 204 Vinayak Hegde Skvělý software se nebuduje, ale vyvíjí........................... 206 Bill de hóra Přispěvatelé.................................................... 208 Rejstřík......................................................... 221 Obsah 9

Předmluva Softwaroví architekti mají ve světě IT unikátní postavení. Očekává se od nich znalost technologií a softwarových platforem používaných ve společnostech, kde působí, stejně tak jako znalost předmětu jejich podnikání. Dobrý softwarový architekt musí zvládat obě strany mince byznys i technologie. To není ni kterak jednoduchý úkol, a také proto vznikla tato kniha. Kniha 97 klíčových znalostí softwarového architekta vám přináší nejrůznější rady od softwarových architektů z celého světa tím, jak se vyhnout běžným úskalím, počínaje a sestavováním talentovaných týmů konče. Jedná se o rozmanitou kompilaci rad od uznávaných softwarových architektů pro další softwarové architekty anebo pro ty, kteří by se jimi rádi stali. Upřímně doufám, že tato kniha bude zdrojem inspirace a informací pro softwarové profesionály celého světa. Doufám také, že softwaroví architekti tuto knihu a její dceřiný web použijí ke sdílení rad a názorů k jedné z možná nejnáročnějších profesí v oblasti informačních technologií současnosti. Tato kniha se pravděpodobně liší od všech ostatních, které jste kdy četli. Jedná se o výsledek společné práce více než čtyř desítek autorů, kteří bez nároku na honorář poskytli své znalosti a rady týkající se architektury softwaru. Do značné míry se tedy jedná o open source knihu v tom nejpravějším slova smyslu. Každý z autorů poskytl své příspěvky, které zkontroloval a upravil, a ty nejlepší z nich se dočkaly publikace. To se příliš neliší od open source softwarového projektu, kde jednotlivci místo vědomostmi a moudrostí přispívají svým kódem. 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. Existuje mnoho pokusů vydat volně šiřitelnou publikaci. Většina z nich, až na pár výjimek, však neuspěla. Myslím si, že za tím stojí jeden důvod. Pro jednotlivce je těžké přispívat do knihy, která není modularizována. Právě proto, že je každý článek celistvý a lze jej používat jak samostatně, tak spolu s ostatními, má tato kniha šanci na úspěch. Předmluva 11

Poděkování Myšlenka knihy 97 klíčových znalostí softwarového architekta nevznikla ve vakuu. Je mnoho lidí, kteří si zaslouží poděkování za myšlenku i její realizaci. Chtěl bych poděkovat Jayi Zimmermanovi, který navrhl, abych udělal prezentaci pro sympozium No Fluff, Just Stuff nazvanou 10 klíčových znalostí softwarového architekta ; dále pak Bruci Eckelovi za řízení konference, na jejímž základě vznikla myšlenka realizovat tuto knihu; Jeremymu Meyerovi za nápad udělat knihu podobně jako prezentaci; Nitinu Borwankarovi, jenž navrhl zřídit veřejnou Wiki, aby kdokoliv mohl do knihy přispět, a členům konference Bruce, kteří přislíbili věnovat svůj čas a přispět prvními příspěvky do knihy. Také chci poděkovat desítkám softwarových architektů, kteří na svém příspěvku tvrdě pracovali, a přesto se do knihy nedostali. Bylo hodně těžké vybrat, které tipy se dostanou do finální knihy. Ještě jednou díky všem, kteří přispěli, ať už v knize jsou nebo ne. O Reilly patří dík za vyslyšení myšlenky a přispění mnoha radami, které pomohly při realizování knihy. Speciálně bych z O Reilly chtěl poděkovat Miku Loukidesovi, Miku Hendricksonovi, Lauře Painterové a Laurelu Ackermanovi. Bez jejich pomoci by tento projekt nikdy nevznikl. Poznámka redakce českého vydání Nakladatelství a vydavatelství 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/k1806. 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. 12 97 klíčových znalostí softwarového architekta

Požadavky mají přednost před vaším životopisem Nitin Borwankar Jako inženýři někdy doporučujeme technologie, metodologie a postupy pro řešení problémů, protože tam někde hluboko uvnitř toužíme mít je v životopise, a ne proto, že se jedná o nejlepší řešení problému. Taková rozhodnutí však velmi zřídka vedou k dobrým výsledkům. Pro vaši kariéru je nejlepší dlouhý seznam spokojených zákazníků, ochotných vás doporučit, protože jste pro ně a projekt udělali to nejlepší. Tato důvěra vám zajistí příliv objednávek v mnohem větším množství než nejnovější objekt v nejnovějším jazyce využívající nejnovější paradigma. Přestože je důležité, dokonce kriticky, držet krok s nejnovějšími trendy a technologiemi, nemělo by se tak nikdy dít na úkor zákazníka. Pamatujte, že do vás zákazník vkládá svou důvěru. Jako architekt musíte dbát na prosperitu vaší společnosti a očekává se od vás, že se vyhnete všem konfliktům zájmů a budete ke společnosti zcela loajální. Pokud projekt není dostatečně průlomový nebo není dostatečnou výzvou, kterou byste pro svou kariéru potřebovali, najděte takový, který je. 14 97 klíčových znalostí softwarového architekta

Pokud to nedokážete a jste nuceni se takového projektu účastnit, bude pro vás i všechny ostatní lepší, použijete-li technologii vhodnou pro zákazníka, a ne pro váš životopis. Je často obtížné odolat použití řešení, které je nové a in, i když pro aktuální situaci není nejvhodnější. Zvolíte-li to správné řešení, bude projektový tým i zákazník šťastnější a celkově bude projekt doprovázet mnohem méně stresu. To vám mnohdy dá čas ponořit se hlouběji do existující starší technologie nebo se ve svými volném čase naučit nové věci. Anebo se zúčastnit toho kurzu malování, na který jste vždycky chtěli jít. Také vaše rodina vás bude za toto rozhodnutí milovat všimnou si rozdílu hned, jak přijdete domů. Vždy upřednostňujte dlouhodobé potřeby zákazníka před vašimi krátkodobými ambicemi a neuděláte chybu. 15

Zabraňte esenciální složitosti, odstraňte nahodilou složitost Neal Ford Esenciální složitost představuje obtíž, která je neodmyslitelnou součástí každého problému. Např. koordinace leteckého provozu na národní úrovni je jistě složitý problém. Přesnou pozici každého letadla (včetně výšky), rychlost, směr a cílovou destinaci je třeba v reálném čase sledovat, aby se zabránilo kolizím ve vzduchu i na ranveji. Letové plány letadel je třeba spravovat tak, aby se zabránilo zácpám v neustále se měnícím prostředí vážná změna počasí může celý plán výrazně narušit. Naopak nahodilá složitost vychází z věcí, u nichž cítíme, že je musíme vytvořit, abychom zmírnili esenciální složitost. Dnes používaný zastaralý systém letového provozu je příkladem nahodilé složitosti. Byl navržen za účelem řešení esenciál ní složitosti řízení provozu tisícovek letadel, řešení samotné však přináší svou vlastní komplexitu. Systém pro řízení letového provozu, který se dnes používá, je ve skutečnosti tak složitý, že je jeho změna velmi obtížná, ne-li nemožná. Ve většině světa se letový provoz řídí technologií, která je více než 30 let stará. Mnoho frameworků a řešení třetích stran má symptomy nahodilé složitosti. Frameworky řešící určité problémy jsou užitečné. Předimenzované frameworky však přidávají více složitosti, než kolik samy řeší. Složitost přitahuje vývojáře jako magnet často se stejným výsledkem. Řešení hádanek je zábava a vývojáři jsou řešitelé problémů. 16 97 klíčových znalostí softwarového architekta

Kdo by neměl rád ten pocit z vyřešení nějakého velice složitého problému? Při vývoji softwaru je však odstraňování nahodilé složitosti a současně uchránění řešení od esenciální složitosti skutečnou výzvou. Jak postupovat? Dejte přednost frameworkům vytvořeným na základě funk čního kódu namísto těm vytvořeným na základě teoretických předpokladů. Podívejte se na procento kódu vašeho řešení, jež přímo řeší daný problém, a porovnejte ho s množstvím kódu, který pouze řeší rozhraní mezi aplikací a uživatelem. K řešením třetích stran přistupujte ostražitě. Nemusí být z podstaty špatná, ale často trpí nahodilou složitostí. Ujistěte se, že řešení je pro daný problém vhodné. Je povinností architekta řešit problémy a jejich esenciální složitost, aniž by zavedl nahodilou složitost. 17

Váš největší problém pravděpodobně nebude technického rázu Mark Ramm Právě teď někdo řídí neúspěšný projekt, jehož cílem je vytvoření systému pro tisk výplatních pásek. A pravděpodobně bude takových lidí více. Proč? Zvolili snad jazyk Ruby namísto Javy nebo Python namísto Smalltalk? Nebo se rozhodli použít databázový systém Postgre namísto Oracle? Anebo použili operační systém Windows, ačkoli správnou volbou byl Linux? Všichni jsme už byli svědky toho, jak použité technologie zapříčinily nezdar projektu. Jaká je však pravděpodobnost, že byl na daný problém jazyk Java skutečně krátký? Většinu projektů budují lidé a ti jsou také základem úspěchu nebo naopak nezdaru. Stojí za to zamyslet se nad tím, jak pomoci těmto lidem uspět. Je velká šance, že je v týmu někdo, o kom si myslíte, že to nedělá správně, a ohrožuje tak projekt. V takových případech potřebujete velmi starou a lety prověřenou technologii, možná dokonce nejdůležitější technickou inovaci v historii celého lidstva konverzaci. Pouhá znalost konverzace coby technologie nestačí. Vědět, jak přistupovat k lidem s respektem a vyvádět je z pochyb, je jednou z klíčových dovedností, které z chytrého architekta učiní efektivního. Přestože je tato problematika velmi obsáhlá, několik dobře mířených rad vám může pomoci významně zvýšit vaši efektivitu při konverzaci: Přistupujte k této aktivitě jako ke konverzaci, a ne ke konfrontaci. Pokud si o lidech myslíte jen to nejlepší a konverzaci chápete jako příležitost klást dotazy, určitě se dozvíte více a s menší pravděpodobností uvedete lidi do defenzivy. 18 97 klíčových znalostí softwarového architekta

Ke konverzaci přistupujte pouze ve správném rozpoložení. Pokud jste naštvaní, frustrovaní, rozzlobení nebo jinak zneklidnění, je velmi pravděpodobné, že druhá osoba interpretuje vaši neverbální komunikaci jako pokus o útok. Využijte konverzaci jako příležitost nastavit společné cíle. Místo toho, abyste vývojáře požádali, aby na schůzkách mlčel, protože nikdy nikoho nepustí ke slovu, požádejte ho, jestli by nepomohl zvýšit účast ostatních v diskusi. Vysvětlete mu, že jsou někteří lidé introverti a potřebují delší odmlky, než vstoupí do diskuse. Požádejte ho, aby pět vteřin vyčkal, než vstoupí do konverzace. Pokud budete problémy ostatních chápat jako příležitost se něčemu přiučit a udržíte na uzdě své emoce, zjistíte, že jste nejenom efektivnější, ale také, že se pokaždé něco dozvíte. 19