軟件架構師的12項修煉：技術技能篇 pdf epub mobi txt 電子書下載 2025

簡體網頁||繁體網頁

☆☆☆☆☆

[美] 戴維·亨德裏剋森（Dave Hendricksen）著，姚軍譯

下載連結在頁面底部

facebook linkedin mastodon messenger pinterest reddit telegram twitter viber vkontakte whatsapp 複製連結

想要找書就要到靜流書站

windowsfront.com

立刻按 ctrl+D收藏本頁

你會得到大驚喜!!

齣版社：機械工業齣版社

ISBN：9787111506980

版次：1

商品編碼：11740744

品牌：機工齣版

包裝：平裝

開本：16開

齣版時間：2015-07-01

用紙：膠版紙

頁數：213

具體描述

編輯推薦

　　《軟件架構師的12項修煉》姊妹篇，迴歸架構工作的技術本源，探尋成功架構師必備的技術技能

　　從解決方案的概念化到平颱開發及治理，從技術創新的選擇到為架構注入企業精神，指明個人和團隊在架構工作中的全麵提升之道

　　精通每位軟件架構師都需要的關鍵技術技能！

　　作為軟件架構師，要想取得成功就必須兼具技術技能和軟技能。Dave Hendricksen在其暢銷的《軟件架構師的12項修煉》中闡明成為成功軟件架構師所必需的三大軟技能：關係技能、個人技能和商務技能。現在，他又轉嚮技術技能。從數十年的經驗中，Hendricksen將技術技能組織為三個領域。

　　項目技能：從構思開始推進項目，直至交付

　　技術技能：構建、購買或者利用正確的技術

　　想象力技能：實現增強長期競爭力的架構願景

　　從解決方案的概念化到平颱開發及治理，從技術創新的選擇到為架構注入企業精神，本書將幫助你拓展和磨練這些關鍵技術技能。

　　《軟件架構師的12項修煉：技術技能篇》揭示瞭架構師所需要的技術技能，提供瞭掌握它們所需的清晰框架及實用方法學。

　　Hendricksen的兩本書共同提供瞭軟件架構師邁嚮優秀的完整、實用的路徑。它們將指導你架構生涯的每一步——從占據閤適的位置到之後的成長。

內容簡介

　　《軟件架構師的12項修煉：技術技能篇》是資深架構師DaveHendricksen的力作，係統闡述瞭成功架構師的必備技術技能，以及個人及團隊拓展、應用這些技能的方法。本書分為3個部分，一部分（第1~5章）介紹項目技能，涵蓋閤作關係、發現、概念化、估算、管理；第二部分（第6~9章）介紹技術技能，涵蓋平颱開發、架構透視、治理和技術訣竅；第三部分（第10~12章）介紹想象力技能，涵蓋技術創新、戰略路綫圖和企業執行。

作者簡介

　　Dave Hendricksen，全球三大谘詢提供商湯姆森路透集團（Thomson Reuters）公司資深軟件架構師，在軟件架構方麵有非常深的造詣。在公司中，他與新産品開發團隊緊密閤作，為大規模在綫平颱（如Westlaw.com）創建新穎的法律産品。Hendricksen曾在卡內基梅隆大學具有影響力的軟件工程學院做過題為“在敏捷世界中設計和構建大規模係統”的演講。

　　姚軍，曾在多傢證券公司擔任IT經理，在軟硬件項目實施、網絡管理及應用領域有15年以上的工作經驗，自2006年以來已有多部譯作齣版。

譯者序
前言
緻謝
第一部分　項目技能
第1章　閤作關係 5
1.1　什麼是閤作關係 6
1.2　閤作關係的關鍵特徵 6
1.3　一緻 7
1.3.1　我需要和誰結成閤作夥伴 7
1.3.2　找齣思想領袖 8
1.3.3　認識影響力人物 8
1.3.4　確定可信的建議者 9
1.3.5　社區評審（架構評審委員會） 9
1.3.6　在做齣關鍵決策之前尋求一緻 9
1.3.7　共同願景的一緻成就閤作關係 10
1.4　信任 10
1.4.1　建立信任 10
1.4.2　建立公開披露機製 10
1.4.3　避免將攤子鋪得過大（過度投入） 11
1.4.4　在你過度承諾之後如何解脫 12
1.4.5　學會說“不” 12
1.4.6　信任帶來透明度—閤作關係的命脈 13
1.5　語境 14
1.5.1　瞭解閤作的性質 14
1.5.2　瞭解你的業務背景（語境） 14
1.5.3　技術決策需要閤作關係 14
1.5.4　關鍵點：技術決策是政治決策 15
1.5.5　首先介紹情況（提供語境） 15
1.5.6　支持你的閤作夥伴 16
1.5.7　為閤作夥伴的成功做齣貢獻 17
1.5.8　人多勢眾 17
1.6　協作 17
1.6.1　將價值放到颱麵上 17
1.6.2　成為導師 17
1.6.3　尋找導師 18
1.6.4　閤作關係可能是機遇之源 19
1.6.5　閤作關係是邁嚮構思的一步 19
1.6.6　協作推動更強大的閤作關係 19
1.7　關係 19
1.7.1　閤作關係不僅和業務有關 19
1.7.2　想要索取就要先付齣 20
1.7.3　外部閤作關係 20
1.7.4　過去的不愉快經曆 20
1.7.5　躲開組織中的刻薄鬼 20
1.8　小結 21
參考書目 22
第2章　發現 23
2.1　什麼是發現 24
2.2　發現的關鍵 25
2.3　瞭解客戶 25
2.3.1　與銷售、市場及新産品開發部門建立閤作關係 26
2.3.2　與客戶會麵 29
2.3.3　取悅客戶的是什麼 33
2.4　瞭解市場 34
2.4.1　瞭解客戶的客戶 35
2.4.2　客戶願意在哪裏花錢 36
2.4.3　競爭對手在做什麼 37
2.4.4　傾聽不同客戶的主題 38
2.5　理解你的業務 39
2.5.1　研究你的業務目標 39
2.5.2　個性化公司的戰略目標 39
2.5.3　為決策開發一個業務語境 40
2.6　小結 40
參考書目 41
第3章　概念化 42
3.1　構思 43
3.2　及早介入 43
3.3　概念化：將生命賦予思路 44
3.4　概念形成 45
3.4.1　他們使用什麼語言 45
3.4.2　正在討論的是什麼問題 46
3.4.3　當你較晚進入構思團體中時，需要謹慎投入 48
3.4.4　這個概念是什麼樣子的 49
3.5　概念具體化 51
3.5.1　最小可行性産品 51
3.5.2　試驗的需求 52
3.5.3　建立假設有助於協調願景 53
3.5.4　確定必不可少的功能和客戶角色 53
3.5.5　和客戶一起進行概念具體化 54
3.6　概念演化 54
3.6.1　以史為鑒 54
3.6.2　接受多種視角 55
3.6.3　尋求概念完整性 56
3.6.4　發現鄰近的機遇 57
3.7　小結 57
參考書目 58
第4章　估算 59
4.1　估算概述 60
4.1.1　估算的目的是什麼 61
4.1.2　是否建立瞭項目語境 61
4.1.3　什麼是架構方法 62
4.2　理解估算過程 63
4.2.1　估算管綫 63
4.2.2　項目類型 63
4.2.3　項目籌資的其他方式 64
4.2.4　理解業務過程 65
4.3　開發架構方法 66
4.3.1　是閤作夥伴關係還是閤同關係 66
4.3.2　項目在業務上的依據是什麼 66
4.3.3　營銷方式是什麼 67
4.3.4　是不是重復的估算 67
4.3.5　已經識彆瞭哪些風險？能否緩解 68
4.3.6　是否將構建一個平颱 69
4.3.7　是否將更改平颱 69
4.3.8　使用何種技術 70
4.3.9　采用何種組織結構 70
4.3.10　是否需要進行外部調查 71
4.3.11　是否找齣瞭可利用的組件 71
4.4　估算策略 72
4.4.1　為未知因素和挑戰製訂計劃 72
4.4.2　務實：不要為瞭獲得項目而屈服 72
4.4.3　嚴密控製關鍵因素 73
4.4.4　開發估算反饋循環 73
4.4.5　最大限度地減少組織耦閤和內聚 73
4.4.6　隨身帶著PowerPoint 73
4.4.7　開發檢查列錶 73
4.4.8　及早獲得高管和組織的支持 74
4.5　估算原則 74
4.5.1　確定疑難問題 74
4.5.2　提供選項 74
4.5.3　保持設計決策的開放 74
4.5.4　瞭解時間錶 74
4.5.5　知道你想要的結果 75
4.5.6　避免負麵態度 75
4.5.7　尋找說“是”的機會 75
4.5.8　現在就開始討價還價，不要等到以後 75
4.5.9　不要認輸 75
4.5.10　相信你的直覺 75
4.5.11　瞭解其他人估算過的項目 75
4.5.12　瞭解業務部門的目標價格 76
4.6　完成估算 76
4.6.1　瞭解時限 76
4.6.2　誰參與估算 76
4.6.3　理解你的切入點 76
4.6.4　組閤所有信息 77
4.6.5　與高管人員接觸 77
4.6.6　推銷估算 77
4.7　小結 79
參考書目 80
第5章　管理 81
5.1　架構管理定義 82
5.2　架構師負責的領域 83
5.3　堅持追求技術上的卓越 83
5.3.1　確立一個願景 83
5.3.2　提升技術負債意識，投資閤適的解決方案 83
5.3.3　保持技術環境的趣味性 84
5.3.4　找齣潛在的專利 84
5.3.5　尋求數據中心和運營部門對你的方嚮的支持 85
5.3.6　推廣解決方案 85
5.3.7　建立戰略性解決方案 85
5.3.8　利用現有解決方案 86
5.4　交付項目 86
5.4.1　與項目經理成為閤作夥伴 86
5.4.2　無情地消除依賴性 86
5.4.3　管理預期 87
5.4.4　控製開發過程 87
5.4.5　在發生問題時齣現 88
5.4.6　瞭解項目上不透明的因素 88
5.4.7　限製處於領導地位的承包商數量 88
5.4.8　提供技術管理（職責領域） 89
5.4.9　應急管理 89
5.5　解決問題 90
5.5.1　提齣難題 90
5.5.2　立即處理問題 90
5.5.3　說“不”，但是要提齣選項 90
5.5.4　在決策中努力保持一緻 91
5.5.5　學會正麵處理問題、攤牌 92
5.5.6　知道在協商中你所願意接受的 92
5.5.7　勇於對不同意的領域（有禮貌地）提齣挑戰 92
5.5.8　堅持立場 92
5.5.9　知道哪些不是你的問題 92
5.6　與高管人員成為閤作夥伴 93
5.6.1　通過透明度管理風險 93
5.6.2　審核估算 93
5.6.3　限製框圖中方框的數量 93
5.6.4　提升技術意識 93
5.6.5　支持老闆 94
5.6.6　不要打斷高管人員的講話 94
5.6.7　保持自信 94
5.7　管理你的時間 94
5.7.1　限製投入的項目數量 94
5.7.2　定義自己的角色並堅持 95
5.7.3　確定費時工作的優先級 95
5.7.4　學會在限定的日期和時間做齣決策 96
5.7.5　隻在你是活躍的參與者時纔參加會議 96
5.7.6　瞭解最後期限 96
5.7.7　委托你信任的人 96
5.7.8　麵對麵會談 96
5.8　培養技術人纔 97
5.8.1　製定架構導師計劃 97
5.8.2　建立技術論壇 97
5.8.3　鼓勵技術團隊成員參與當地的會議和用戶組 98
5.8.4　雇用最好的員工：不隻是填補一個職位 98
5.9　提高技能 99
5.9.1　與其他架構師坐在一起 99
5.9.2　每天做一些技術工作 99
5.9.3　專注於令你吃驚的事情 99
5.9.4　成為某個領域的專傢 99
5.9.5　尋求能夠提高技能的項目 99
5.10　小結 100
參考書目 100
第二部分　技術技能
第6章　平颱開發 106
6.1　平颱開發定義 107
6.2　平颱開發的要素 107
6.3　功能 108
6.3.1　定義目標集 108
6.3.2　定義功能集 108
6.3.3　專注於可利用功能 109
6.3.4　開發強大的概念模型 109
6.3.5　API是“打開王國的鑰匙” 109
6.4　生態係統 110
6.4.1　平颱用戶 110
6.4.2　平颱所有權 110
6.4.3　平颱管理 115
6.4.4　平颱開發 117
6.4.5　認識與平颱相關的成本 118
6.4.6　管理平颱質量 119
6.4.7　平颱集成 119
6.4.8　可伸縮性 120
6.4.9　安全性 120
6.5　指導原則 120
6.5.1　追求超卓的質量 120
6.5.2　追求卓越運營 121
6.5.3　可配置性勝過硬編碼 121
6.5.4　追求可利用性 121
6.5.5　追求冗餘架構 121
6.5.6　追求綫性的伸縮性 121
6.5.7　避免平颱纏繞 122
6.5.8　避免平颱蔓延 122
6.5.9　持續升級到最新技術 122
6.6　小結 122
參考書目 123
第7章　架構透視 124
7.1　架構透視的定義 125
7.2　架構原則 126
7.2.1　最少意外原則 126
7.2.2　最少知識原則（迪米特法則） 126
7.2.3　最小工作量原則（齊普夫法則） 127
7.2.4　機會成本原則 127
7.2.5　單一職責原則 128
7.2.6　精簡原則（奧卡姆剃刀或者KISS） 128
7.2.7　最後責任時刻原則（延遲成本） 129
7.2.8　反饋原則 129
7.3　架構關注點 130
7.3.1　可用性 130
7.3.2　可伸縮性 131
7.3.3　可擴展性 132
7.3.4　可重復性 133
7.3.5　兼容性 133
7.3.6　可持續性 133
7.3.7　安全性、災難恢復、業務持續性和開源許可證 134
7.3.8　第三方集成 134
7.4　架構溝通 134
7.4.1　領域模型 134
7.4.2　流程圖 134
7.4.3　環境圖 135
7.4.4　用戶界麵模型 136
7.4.5　邏輯架構框圖 136
7.4.6　執行概況圖 137
7.4.7　硬件環境框圖 137
7.4.8　風險、假設、問題和相互依賴性（RAID） 138
7.5　整閤所有因素 140
7.6　小結 140
參考書目 140
第8章　治理 142
8.1　治理的定義 143
8.2　治理原則 143
8.2.1　避免供應商鎖定 143
8.2.2　鼓勵開源産品的使用 143
8.2.3　最小化中斷成本（實現業務持續性計劃和災難恢復） 145
8.2.4　實現業務部門之間的鬆散耦閤 146
8.2.5　利用公共功能 146
8.2.6　確保監管依從性 147
8.2.7　確保安全性 148
8.2.8　最小特權原則（最小授權原則） 149
8.2.9　尋求統一身份和訪問管理 149
8.2.10　尋求數據可移植性（避免數據鎖定） 149
8.2.11　尋求集成和自動化 149
8.3　治理的領域 150
8.3.1　估算 150
8.3.2　管理關注點 151
8.3.3　架構 151
8.3.4　設計 152
8.3.5　構建、編碼、集成、部署、測試和監控 153
8.4　使用敏捷方法的治理和健康壓力 153
8.5　小結 154
參考書目 154
第9章　技術訣竅 155
9.1　技術訣竅的定義 156
9.2　開發訣竅 156
9.2.1　發展與技術訣竅的聯係 156
9.2.2　發展技術訣竅的先進性 159
9.2.3　發展技術訣竅的卓越性 161
9.2.4　技術訣竅綜閤體 167
9.3　技術訣竅驅動的架構 167
9.4　小結 168
參考書目 169
第三部分　想象力技能
第10章　技術創新 174
10.1　技術創新的定義 175
10.2　趨勢感知 176
10.2.1　趨勢感知的領域 176
10.2.2　應用趨勢感知 177
10.3　業務融閤 178
10.3.1　注意客戶谘詢中的趨勢 178
10.3.2　獲得客戶反饋 178
10.3.3　分析客戶反饋 179
10.3.4　何時要對趨勢保持警惕 179
10.3.5　何時接受趨勢 180
10.4　戰略性研究 180
10.5　技術創新原則 181
10.5.1　尋求得到批準的最少研究時間和資金 182
10.5.2　下小的賭注 182
10.5.3　定期使用技術搜索瀏覽和跟蹤趨勢 182
10.5.4　建立實驗室區域 183
10.5.5　運用具備用戶反饋循環的快速試驗 183
10.5.6　嚮業務部門和客戶展示原型 183
10.5.7　在係統邊緣上引入新技術 184
10.6　實用技術創新 185
10.7　小結 186
參考書目 186
第11章　戰略路綫圖 187
11.1　戰略路綫圖的定義 188
11.2　戰略路綫圖的要素 188
11.2.1　戰略要點 188
11.2.2　時序 189
11.2.3　用“泳道”組織 189
11.2.4　依賴性感知 189
11.2.5　直觀錶示 189
11.2.6　協作特性 189
11.2.7　代碼命名 189
11.2.8　上下文相關（個性化） 190
11.2.9　多學科和專業性 190
11.2.10　優先級排定 190
11.2.11　迭代特性 190
11.2.12　更新 190
11.2.13　發布 190
11.2.14　可計量 190
11.3　路綫圖製定策略 191
11.3.1　在白闆上用即時貼演示路綫圖 191
11.3.2　從終點開始（反嚮推導） 191
11.3.3　召開研討會 191
11.3.4　將戰略路綫圖視為項目 191
11.3.5　捕捉基本指導原則 192
11.4　路綫圖製定原則 192
11.4.1　保持簡單 192
11.4.2　與業務部門閤作 192
11.4.3　行動起來 192
11.4.4　尋找樂趣 192
11.4.5　沒有目標的戰略毫無意義 193
11.4.6　識彆需要研究和創新的領域 193
11.4.7　識彆技能和知識的不足 193
11.4.8　在實現目標的時間上保持靈活 193
11.4.9　勇於嘗試新路徑 193
11.4.10　路綫圖與細節無關，重點是目標和關鍵裏程碑 194
11.4.11　追隨能夠激勵你的方嚮 194
11.5　架構師在路綫圖製定中的角色是什麼 195
11.6　路綫圖可能用於哪些地方 195
11.7　路綫圖考慮因素 195
11.8　路綫圖社會化 196
11.9　慶祝裏程碑的實現 198
11.10　小結 198
參考書目 198
第12章　企業執行 200
12.1　企業執行的定義 201
12.2　企業執行的要素 202
12.2.1　企業精神 202
12.2.2　承受預期風險 203
12.2.3　交付成果 203
12.3　企業執行原則 204
12.3.1　可承受損失原則 204
12.3.2　檸檬水原則 204
12.3.3　拼花布原則 204
12.3.4　一鳥在手原則 204
12.3.5　飛機駕駛員原則 205
12.3.6　把握時機 205
12.3.7　追隨愛好 205
12.3.8　學會變通 205
12.3.9　以高成本效益的方式在實踐中學習和犯錯 207
12.3.10　尋求反饋 207
12.3.11　尋求可利用機會 208
12.4　以企業執行推動架構 209
12.5　小結 209
參考書目 210
結語　組閤所有技能 212

精彩書摘

　　在構思階段一開始就參與，對設計交付解決方案的備選途徑有顯著的影響。這種語境在項目後期或者從這一構思衍生齣來的其他項目中是很有價值的。　　及早參與從根本上改變瞭你的角色，從解決方案提供商／承包商變成閤作夥伴（坐在會議桌旁，貢獻最好、最有前途思路的人）。如果你較晚進入這一過程，概念的許多邊界已經確立，改變決策的熱情就會受到限製。　　讓客戶參與構思（找齣他們的真正問題、願意花錢的地方以及現在處理問題的方式）能夠顯著改善你的能力，理解需要製作什麼樣的産品，以及産品的工作方式。　　如果客戶參與，在溝通中要付齣辛勤的努力。一般來說，業務人員很害怕技術人員在交流中引入“呆伯特效應”。　　在開始時保持謹慎，努力建立信任；你必須證明自己在公眾麵前是個“好市民”，纔能開始施加影響。傾聽各種客戶對所提齣概念的反應，對其形成、大小和復雜性有顯著的影響。我個人曾經見過許多比客戶的實際需求復雜得多的概念。　　將問題暴露給多個客戶（當然是根據保密協議，並為他們花費的時間和精力提供報酬）對概念進行持續求精，可以清晰地理解之前從未齣現的情況，開始為概念形成簡潔（去掉不必要的因素）的結構，最終，可能隻需要一小部分成本就能夠實現。　　我曾經見過一個案例，由於客戶及早介入，最終的解決方案成本隻有最初估計的10%，而且解決方案更具有戰略性（關注少量關鍵因素，以它們為基礎交付成果），適用於許多不同的業務機遇。　　……

前言/序言

　　“架構不是懦弱、意誌薄弱或者短命的人從事的職業。”　　—Martin Filler“架構和建築物與你如何繞過麵前的障礙息息相關。有時候這決定瞭你的成功：你是否擅長繞過障礙？”　　—Jeremy Renner“建築是一項服務。建築師得到項目、預算、工作場所和時間錶。有時候，最終産品會成為一件藝術品—至少人們會這麼稱呼它。”　　—Frank Gehry“建築就是創造。”　　—Oscar Niemeyer“我熱愛邏輯、數學、計算機編程。我熱愛係統和邏輯方法。而我認為建築是這三者的完美組閤。”　　—林瓔“我總是在思考建築的問題，那是一個問題。但是我一直喜歡它，有時會夢見它。”　　—Zaha Hadid“互聯網可能是我一生遇見的最為重要的技術進步。它的優勢在於開放的架構和讓所有人的聲音都被其他人聽到的框架。”　　—Adam Savage本書的創作動機本書和我的第一本書（《軟件架構師的12項修煉》）專注於闡述成功軟件架構師必需的技能。　　軟件架構研究的是和人的關聯以及用架構的眼光去思考的方法。《軟件架構師的12項修煉》注重的是軟技能；沒有這些技能，幾乎不可能走完餘下的“旅途”。　　完成第一本書後不久，我開始接到關於書中提到但是未做討論的假定技術性技能（如圖P.1所示）的問題。　　圖P.1　軟件架構師的12項必備技能本書深入這些假定技能的細節——作為架構師每天都需要用到的技術能力。將軟技能和技術技能相結閤，纔能幫助你實現目標。　　本書的目標本書的目標是：　　通過技能拓展實現卓越的軟件架構實現商業環境下的成功架構促進企業思維中的架構方法本書的組織本書的格式與風格旨在幫助你批判性地思考自己的項目集、架構監管領域和具有領導力的領域。這些領域的知識分彆以項目技能、技術技能和想象力技能的形式齣現。　　這三個領域組織為：　　第一部分：項目技能。通過如下技能，幫助你推動項目，使其從早期的構想成為可交付的成果：　　閤作關係（第1章）發現（第2章）概念化（第3章）估算（第4章）管理（第5章）第二部分：技術技能。如下技能確保你能構建、購買或者利用正確的技術：　　平颱開發（第6章）架構透視（第7章）治理（第8章）技術訣竅（第9章）第三部分：想象力技能。通過如下技能，幫助你追求企業長期競爭願景：　　技術創新（第10章）戰略路綫圖（第11章）企業執行（第12章）這三個部分可以看作軟件架構師技能的層次化結構（見圖P.2），每一層都是上一層的基礎。　　本書的每一章都可以獨立於其他章節進行閱讀。這種獨立性使你可以按照自己的興趣，或者需求順序閱讀。　　我希望你喜歡本書，並從中學到新鮮的知識，幫助你成為齣色的架構師，更好地理解架構師這一角色。　　如果你有任何問題或者意見，請和我聯係g。　　圖P.2　技術技能金字塔Acknowledgements　緻　　謝我要嚮Addison-Wesley齣色的員工們說聲謝謝，特彆要感謝Olivia Basegio、Sheri Cain、Chris Guzikowski、Chuti Presertsith、Kesel Wilson和Barbara Wood。與他們一起工作是很奇妙的經曆。　　感謝Brad Appleton、Kevin Bodie、Robert Marksimchuk和一位不願意留下姓名的審稿人審閱瞭本書的第一稿，並為我提供瞭很好的反饋。　　我還要感謝來自Thomson Reuters的審稿人，他們是：Mick Atton、Dan Bennett、Cary Felbab、Scott Fancis、Kevin Hakanson、Jesse Haraldson、James Jarvis、Andrew Lipstein、Andrew Martens、Lynn Meredith、Scott Post、Noah Pruzek、Chris Rowland、Bob Sturm、Bas Vellekoop和Justin Wright。每位審稿人都審閱瞭所在專業領域的章節。　　此外，我還要感謝妻子Jennifer、兒子Tim審閱瞭本書。　　最後，我要感謝傢人和父母，感謝他們對我編寫本書的支持。