軟體架構師應該知道的97件事
軟體架構師應該知道的97件事
基本資訊
- 作者:Richard Monson-Haefel
- 譯者: 徐定翔;章顯洲
- 出版社:電子工業出版社
- ISBN:9787121106354
- 上架時間:2010-4-21
- 出版日期:2010 年4月
- 開本:16開
- 其他詳細資訊檢視:
編輯推薦
O’reilly第一本開源圖書,業界專家集體智慧創作 。
旨在“為全世界的軟體架構師提供洞察力和指導”。
集思廣益、覆蓋面廣、寫法新穎 。
技術社群及程式設計師部落格熱議 。
目錄
前言 I
客戶需求重於個人簡歷 2
尼廷·博萬卡(Nitin Borwankar)
簡化根本複雜性,消除偶發複雜性 4
尼爾·福特(Neal Ford)
關鍵問題可能不是出在技術上 6
馬克·蘭姆(Mark Ramm)
以溝通為中心,堅持簡明清晰的表達方式和開明的領導風格 8
馬克·理查茲(Mark Richards)
架構決定效能 10
蘭迪·斯塔福德(Randy Stafford)
分析客戶需求背後的意義 12
埃納爾·蘭德雷(Einar Landre)
起立發言 14
烏迪·大漢(Udi Dahan)
故障終究會發生 16
邁克爾·尼加德(Michael Nygard)
我們常常忽略了自己在談判 18
邁克爾·尼加德(Michael Nygard)
量化需求 20
客戶需求重於個人簡歷 2
尼廷·博萬卡(Nitin Borwankar)
簡化根本複雜性,消除偶發複雜性 4
尼爾·福特(Neal Ford)
關鍵問題可能不是出在技術上 6
馬克·蘭姆(Mark Ramm)
以溝通為中心,堅持簡明清晰的表達方式和開明的領導風格 8
馬克·理查茲(Mark Richards)
架構決定效能 10
蘭迪·斯塔福德(Randy Stafford)
分析客戶需求背後的意義 12
埃納爾·蘭德雷(Einar Landre)
起立發言 14
烏迪·大漢(Udi Dahan)
故障終究會發生 16
邁克爾·尼加德(Michael Nygard)
我們常常忽略了自己在談判 18
邁克爾·尼加德(Michael Nygard)
量化需求 20
.基思·佈雷思韋特(Keith Braithwaite)
一行程式碼比五百行架構說明更有價值 22
艾利森·蘭德爾(Allison Randal)
不存在放之四海皆準的解決方案 24
蘭迪·斯塔福德(Randy Stafford)
提前關注效能問題 26
麗貝卡·帕森斯(Rebecca Parsons)
架構設計要平衡兼顧多方需求 28
蘭迪·斯塔福德(Randy Stafford)
草率提交任務是不負責任的行為 30
尼克拉斯·尼爾森(Niclas Nilsson)
不要在一棵樹上吊死 32
基思·佈雷思韋特(Keith Braithwaite)
業務目標至上 34
戴夫·繆爾黑德(Dave Muirhead)
先確保解決方案簡單可用,再考慮通用性和複用性 36
凱佛林·亨尼(Kevlin Henney)
架構師應該親力親為 38
約翰·戴維斯(John Davies)
持續整合 40
大衛·巴特利(David Bartlett)
避免進度調整失誤 42
諾曼·卡諾瓦利(Norman Carnovale)
取捨的藝術 44
馬克·理查茲(Mark Richards)
打造資料庫堡壘 46
丹·恰克(Dan Chak)
重視不確定性 48
凱佛林·亨尼(Kevlin Henney)
不要輕易放過不起眼的問題 50
戴夫·奎克(Dave Quick)
讓大家學會複用 52
傑里米·邁耶(Jeremy Meyer)
架構裡沒有大寫的“I” 54
戴夫·奎克(Dave Quick)
使用“一千英尺高”的檢視 56
埃裡克·多倫伯格(Erik Doernenburg)
先嚐試後決策 58
埃裡克·多倫伯格(Erik Doernenburg)
掌握業務領域知識 60
馬克·理查茲(Mark Richards)
程式設計是一種設計 62
埃納爾·蘭德雷(Einar Landre)
讓開發人員自己做主 64
菲利普·尼爾森(Philip Nelson)
時間改變一切 66
菲利普·尼爾森(Philip Nelson)
設立軟體架構專業為時尚早 68
巴里·霍金斯(Barry Hawkins)
控制專案規模 70
大衛·奎克(Dave Quick)
架構師不是演員,是管家 72
巴里·霍金斯(Barry Hawkins)
軟體架構的道德責任 74
邁克爾·尼加德(Michael Nygard)
摩天大廈不可伸縮 76
邁克爾·尼加德(Michael Nygard)
混合開發的時代已經來臨 78
愛德華·加森(Edward Garson)
效能至上 80
克雷格·羅素(Craig Russell)
留意架構圖裡的空白區域 82
邁克爾·尼加德(Michael Nygard)
學習軟體專業的行話 84
馬克·理查茲(Mark Richards)
具體情境決定一切 86
愛德華·加森(Edward Garson)
侏儒、精靈、巫師和國王 88
埃文·考夫斯基(Evan Cofsky)
向建築師學習 90
基思·佈雷思韋特(Keith Braithwaite)
避免重複 92
尼克拉斯·尼爾森(Niclas Nilsson)
歡迎來到現實世界 94
格雷戈爾·侯珀(Gregor Hohpe)
仔細觀察,別試圖控制一切 96
格雷戈爾·侯珀(Gregor Hohpe)
架構師好比兩面神 98
大衛·巴特利(David Bartlett)
架構師當聚焦於邊界和介面 100
埃納爾·蘭德雷(Einar Landre)
助力開發團隊 102
蒂莫西·海伊(Timothy High)
記錄決策理由 104
蒂莫西·海伊(Timothy High)
挑戰假設尤其是你自己的 106
蒂莫西·海伊(Timothy High)
分享知識和經驗 108
保羅·W·霍默(Paul W. Homer)
模式病 110
查德·拉·瓦因(Chad La Vigne)
不要濫用架構隱喻 112
戴維·英格(David Ing)
關注應用程式的支援和維護 114
門西蒂西·卡斯珀(Mncedisi Kasper)
有舍才有得 116
比爾·德·霍拉(Bill de hóra)
先考慮原則、公理和類比再考慮個人意見和口味 118
邁克爾·哈默(Michael Harmer)
從“可行走骨架”開始開發應用 120
克林特·尚克(Clint Shank)
資料是核心 122
保羅·W·霍默(Paul W. Homer)
確保簡單問題有簡單的解 124
查德·拉·瓦因(Chad La Vigne)
架構師首先是開發人員 126
邁克·布朗(Mike Brown)
根據投資回報率(ROI)進行決策 128
喬治·馬拉米迪斯(George Malamidis)
一切軟體系統都是遺留系統 130
戴夫·安德森(Dave Anderson)
起碼要有兩個可選的解決方案 132
蒂莫西·海伊(Timothy High)
理解變化的影響 134
道格·克勞福德(Doug Crawford)
你不能不瞭解硬體 136
卡邁爾·威克拉瑪納亞克(Kamal Wickramanayake)
現在走捷徑,將來付利息 138
斯科特·麥克菲(Scot Mcphee)
不要追求“完美”,“足夠好”就行 140
格雷格·紐伯格(Greg Nyberg)
小心“好主意” 142
格雷格·紐伯格(Greg Nyberg)
內容為王 144
朱賓·沃迪亞(Zubin Wadia)
對商業方,架構師要避免憤世嫉俗 146
查德·拉·瓦因(Chad La Vigne)
拉伸關鍵維度,發現設計中的不足 148
斯蒂芬·瓊斯(Stephen Jones)
架構師要以自己的程式設計能力為依託 150
邁克·布朗(Mike Brown)
命名要恰如其分 152
薩姆·加德納(Sam Gardiner)
穩定的問題才能產生高質量的解決方案 154
薩姆·加德納(Sam Gardiner)
天道酬勤 156
布賴恩·哈特(Brian Hart)
對決策負責 158
周異(Yi Zhou)
棄聰明,求質樸 160
埃本·休伊特(Eben Hewitt)
精心選擇有效技術,絕不輕易拋棄 162
查德·拉·瓦因(Chad La Vigne)
客戶的客戶才是你的客戶! 164
埃本·休伊特(Eben Hewitt)
事物發展總會出人意料 166
彼得·吉拉德莫斯(Peter Gillard-Moss)
選擇彼此間可協調工作的框架 168
埃裡克·霍索恩(Eric Hawthorne)
著重強調專案的商業價值 170
周異(Yi Zhou)
不僅僅只控制程式碼,也要控制資料 172
查德·拉·瓦因(Chad La Vigne)
償還技術債務 174
伯克哈特·赫夫納蓋爾(Burkhardt Hufnagel)
不要急於求解 176
埃本·休伊特(Eben Hewitt)
打造上手(Zuhanden)的系統 178
基思·佈雷思韋特(Keith Braithwaite)
找到並留住富有激情的問題解決者 180
查德·拉·瓦因(Chad La Vigne)
軟體並非真實的存在 182
查德·拉·瓦因(Chad La Vigne)
學習新語言 184
伯克哈特·赫夫納蓋爾(Burkhardt Hufnagel)
沒有永不過時的解決方案 186
理查德·蒙森-哈費爾(Richard Monson-Haefel)
使用者接受度問題 188
諾曼·卡諾瓦利(Norman Carnovale)
清湯的重要啟示 190
埃本·休伊特(Eben Hewitt)
對終端使用者而言,介面就是系統 192
維納亞克·赫格德(Vinayak Hegde)
優秀軟體不是構建出來的,而是培育起來的 194
比爾·德·霍拉(Bill de hora)
索引 196
一行程式碼比五百行架構說明更有價值 22
艾利森·蘭德爾(Allison Randal)
不存在放之四海皆準的解決方案 24
蘭迪·斯塔福德(Randy Stafford)
提前關注效能問題 26
麗貝卡·帕森斯(Rebecca Parsons)
架構設計要平衡兼顧多方需求 28
蘭迪·斯塔福德(Randy Stafford)
草率提交任務是不負責任的行為 30
尼克拉斯·尼爾森(Niclas Nilsson)
不要在一棵樹上吊死 32
基思·佈雷思韋特(Keith Braithwaite)
業務目標至上 34
戴夫·繆爾黑德(Dave Muirhead)
先確保解決方案簡單可用,再考慮通用性和複用性 36
凱佛林·亨尼(Kevlin Henney)
架構師應該親力親為 38
約翰·戴維斯(John Davies)
持續整合 40
大衛·巴特利(David Bartlett)
避免進度調整失誤 42
諾曼·卡諾瓦利(Norman Carnovale)
取捨的藝術 44
馬克·理查茲(Mark Richards)
打造資料庫堡壘 46
丹·恰克(Dan Chak)
重視不確定性 48
凱佛林·亨尼(Kevlin Henney)
不要輕易放過不起眼的問題 50
戴夫·奎克(Dave Quick)
讓大家學會複用 52
傑里米·邁耶(Jeremy Meyer)
架構裡沒有大寫的“I” 54
戴夫·奎克(Dave Quick)
使用“一千英尺高”的檢視 56
埃裡克·多倫伯格(Erik Doernenburg)
先嚐試後決策 58
埃裡克·多倫伯格(Erik Doernenburg)
掌握業務領域知識 60
馬克·理查茲(Mark Richards)
程式設計是一種設計 62
埃納爾·蘭德雷(Einar Landre)
讓開發人員自己做主 64
菲利普·尼爾森(Philip Nelson)
時間改變一切 66
菲利普·尼爾森(Philip Nelson)
設立軟體架構專業為時尚早 68
巴里·霍金斯(Barry Hawkins)
控制專案規模 70
大衛·奎克(Dave Quick)
架構師不是演員,是管家 72
巴里·霍金斯(Barry Hawkins)
軟體架構的道德責任 74
邁克爾·尼加德(Michael Nygard)
摩天大廈不可伸縮 76
邁克爾·尼加德(Michael Nygard)
混合開發的時代已經來臨 78
愛德華·加森(Edward Garson)
效能至上 80
克雷格·羅素(Craig Russell)
留意架構圖裡的空白區域 82
邁克爾·尼加德(Michael Nygard)
學習軟體專業的行話 84
馬克·理查茲(Mark Richards)
具體情境決定一切 86
愛德華·加森(Edward Garson)
侏儒、精靈、巫師和國王 88
埃文·考夫斯基(Evan Cofsky)
向建築師學習 90
基思·佈雷思韋特(Keith Braithwaite)
避免重複 92
尼克拉斯·尼爾森(Niclas Nilsson)
歡迎來到現實世界 94
格雷戈爾·侯珀(Gregor Hohpe)
仔細觀察,別試圖控制一切 96
格雷戈爾·侯珀(Gregor Hohpe)
架構師好比兩面神 98
大衛·巴特利(David Bartlett)
架構師當聚焦於邊界和介面 100
埃納爾·蘭德雷(Einar Landre)
助力開發團隊 102
蒂莫西·海伊(Timothy High)
記錄決策理由 104
蒂莫西·海伊(Timothy High)
挑戰假設尤其是你自己的 106
蒂莫西·海伊(Timothy High)
分享知識和經驗 108
保羅·W·霍默(Paul W. Homer)
模式病 110
查德·拉·瓦因(Chad La Vigne)
不要濫用架構隱喻 112
戴維·英格(David Ing)
關注應用程式的支援和維護 114
門西蒂西·卡斯珀(Mncedisi Kasper)
有舍才有得 116
比爾·德·霍拉(Bill de hóra)
先考慮原則、公理和類比再考慮個人意見和口味 118
邁克爾·哈默(Michael Harmer)
從“可行走骨架”開始開發應用 120
克林特·尚克(Clint Shank)
資料是核心 122
保羅·W·霍默(Paul W. Homer)
確保簡單問題有簡單的解 124
查德·拉·瓦因(Chad La Vigne)
架構師首先是開發人員 126
邁克·布朗(Mike Brown)
根據投資回報率(ROI)進行決策 128
喬治·馬拉米迪斯(George Malamidis)
一切軟體系統都是遺留系統 130
戴夫·安德森(Dave Anderson)
起碼要有兩個可選的解決方案 132
蒂莫西·海伊(Timothy High)
理解變化的影響 134
道格·克勞福德(Doug Crawford)
你不能不瞭解硬體 136
卡邁爾·威克拉瑪納亞克(Kamal Wickramanayake)
現在走捷徑,將來付利息 138
斯科特·麥克菲(Scot Mcphee)
不要追求“完美”,“足夠好”就行 140
格雷格·紐伯格(Greg Nyberg)
小心“好主意” 142
格雷格·紐伯格(Greg Nyberg)
內容為王 144
朱賓·沃迪亞(Zubin Wadia)
對商業方,架構師要避免憤世嫉俗 146
查德·拉·瓦因(Chad La Vigne)
拉伸關鍵維度,發現設計中的不足 148
斯蒂芬·瓊斯(Stephen Jones)
架構師要以自己的程式設計能力為依託 150
邁克·布朗(Mike Brown)
命名要恰如其分 152
薩姆·加德納(Sam Gardiner)
穩定的問題才能產生高質量的解決方案 154
薩姆·加德納(Sam Gardiner)
天道酬勤 156
布賴恩·哈特(Brian Hart)
對決策負責 158
周異(Yi Zhou)
棄聰明,求質樸 160
埃本·休伊特(Eben Hewitt)
精心選擇有效技術,絕不輕易拋棄 162
查德·拉·瓦因(Chad La Vigne)
客戶的客戶才是你的客戶! 164
埃本·休伊特(Eben Hewitt)
事物發展總會出人意料 166
彼得·吉拉德莫斯(Peter Gillard-Moss)
選擇彼此間可協調工作的框架 168
埃裡克·霍索恩(Eric Hawthorne)
著重強調專案的商業價值 170
周異(Yi Zhou)
不僅僅只控制程式碼,也要控制資料 172
查德·拉·瓦因(Chad La Vigne)
償還技術債務 174
伯克哈特·赫夫納蓋爾(Burkhardt Hufnagel)
不要急於求解 176
埃本·休伊特(Eben Hewitt)
打造上手(Zuhanden)的系統 178
基思·佈雷思韋特(Keith Braithwaite)
找到並留住富有激情的問題解決者 180
查德·拉·瓦因(Chad La Vigne)
軟體並非真實的存在 182
查德·拉·瓦因(Chad La Vigne)
學習新語言 184
伯克哈特·赫夫納蓋爾(Burkhardt Hufnagel)
沒有永不過時的解決方案 186
理查德·蒙森-哈費爾(Richard Monson-Haefel)
使用者接受度問題 188
諾曼·卡諾瓦利(Norman Carnovale)
清湯的重要啟示 190
埃本·休伊特(Eben Hewitt)
對終端使用者而言,介面就是系統 192
維納亞克·赫格德(Vinayak Hegde)
優秀軟體不是構建出來的,而是培育起來的 194
比爾·德·霍拉(Bill de hora)
索引 196
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/16566727/viewspace-660402/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 每個Java軟體架構師都應該知道的20件事Java架構
- 作為軟體工程師你應該知道的100件事 - Harish軟體工程工程師
- 專案經理應該知道的97件事 --譯者序
- 【專案經理應該知道的97件事】三位一體的專案管理專案管理
- 每個黑帶大師都應該知道的10件事(建議收藏)
- IT安全專業人員應該知道的12件事
- 軟體架構師應避免的7種行為 - Daniel Watts架構TTS
- 架構師應該具備哪些思維模型?架構模型
- TOGAF企業架構與軟體架構的對應圖架構
- 軟體架構師或解決方案架構師必讀的五本書 - javarevisited架構Java
- 趣頭條 中介軟體架構師架構
- 軟體架構師需要具備的技能 - Abeysinghe架構
- 架構師都該懂的 CAP 定理架構
- 前端工程師應該知道的yarn知識前端工程師Yarn
- 趣頭條 架構部 急招 中介軟體研發工程師/架構師架構工程師
- 軟體架構師主要工作 - Twitter Moses Macero)架構Mac
- IBM架構師分享:極簡主義軟體架構 - Neal HuIBM架構
- 『翻譯』每個程式設計師第一份工作前應該知道的10件事程式設計師
- 你想知道的2018年軟體開發“10件事”
- 工程師文化:正版軟體應該公司買嗎工程師
- 新手工程師需要知道的 7 件事工程師
- [Flutter翻譯]開始使用Flutter Web之前應該知道的7件事FlutterWeb
- 都說軟體架構要分層、分模組,具體應該怎麼做(二)架構
- 怎樣成長為優秀的軟體架構師?架構
- 務實的軟體架構師是什麼樣?(tpierrain)架構AI
- 軟體測試架構師修煉之道 (二)架構
- 軟體測試架構師修煉之道 (一)架構
- Java軟體架構師-25個關注點Java架構
- 軟體測試架構師受歡迎嗎?架構
- 每個架構師都應該讀的八本經典書籍架構
- 阿里架構師,講述基於微服務的軟體架構模式(附資料)阿里架構微服務模式
- 架構師應該多維度多視角地思考 - Gregor架構Go
- 論軟體架構設計及應用架構
- 軟體架構:問題起源和應對架構
- 架構之:軟體架構漫談架構
- 如何才能成為一名軟體架構師?架構
- 招聘—軟體系統架構師,座標北京知春路架構
- 軟考 - 系統架構設計師(基於中介軟體的開發)架構
- 軟體體系架構的認識架構