《軟體架構師應該知道的97件事》

http://blog.csdn.net/jpr1990/article/details/6743033

本書譯者SeanBV（他的CSDN部落格）整理，推薦給大家。

1．  客戶需求重於個人簡曆 （ Nitin Borwankar ）

客戶需求至上。為了自己的簡曆更炫而採用新技術是沽名釣譽，往往事與願違。

2．  簡化根本複雜性 ，消除偶發複雜性 （ Neal Ford ）

分析問題好比撥雲見月、水落石出。

3．  關鍵問題可能不是出在技術上 （ Mark Ramm ）

團隊同心，其利斷金。

4．  以溝通為中心，堅持簡明清晰的表達方式和開明的領導風格 （ Mark Richards ）

溝通應當言簡意賅、詳略得當，別拖泥 帶水。

5．  架構決定效能 （ Randy Stafford ）

種瓜得瓜，種豆得豆，架構設計也是一 樣道理。

6．  分析客戶需求背後的意義 （ Einar Landre ）

抽絲剝繭，洞見癥結。不要被表面需求 迷惑。

7．  起立發言 （ Udi Dahan ）

起立發言效果更好。

8．  故障終究會發生 （ Michael Nygard ）

應該提前設計預防措施，限制故障。

9．  我們常常忽略了自己在談判 （ Michael Nygard ）

工程師應該適時轉換角色，學習談判的 技巧。

10． 量化需求 （ Keith Braithwaite ）

沒有規矩，不成方圓。

11． 一行代碼比五百行架構說明更有價值 （ Allison Randal ）

可工作的代碼才是目標，設計只是達成 目標手段。

12． 不存在放之四海皆準的解決方案 （ Randy Stafford ）

軟體世界沒有萬能鑰匙。

13． 提前關注效能問題 （ Rebecca Parsons ）

儘早展開效能測試。 

14． 架構設計要平衡兼顧多方需求 （ Randy Stafford ）

平衡兼顧項目的技術需求和相關各方的業務需求。

15． 草率提交任務是不負責任的行為   （ Niclas Nilsson ）

要設法杜絕開發人員草率提交任務的念頭。

16． 不要在一棵樹上弔死   （ Keith Braithwaite ）

為客戶提供多樣化的解決方案。

17． 營運目標至上 （ Dave Muirhead ）

技術決策不能脫離營運目標和現實條件的約束。

18． 先確保解決方案簡單可用，再考慮通用性和複用性   （ Kevlin Henney ）

19． 架構師應該親曆親為 （ John Davies ）

身先士卒才能贏得同事的信任。

20． 持續整合 （ David Bartlett ）

21． 避免進度調整失誤 （ Norman Carnovale ）

不惜一切代價拒絕調整項目進度的要求。

22． 取捨的藝術 （ Mark Richards ）

架構不可能滿足所有需求。

23． 打造資料庫堡壘 （ Dan Chak ）

一開始就要定義好資料模型。

24． 重視不確定性 （ Kevlin Henney ）

延遲決策，建設性地利用不確定性。

25． 不要輕易放過不起眼的問題 （ Dave Quick ）

別忘了溫水煮青蛙的故事。

26． 讓大家學會複用 （ Jeremy Meyer ）

重複利用已有資源，首先要改變大家的觀念。

27． 架構裡沒有大寫的“I ” （ Dave Quick ）

變讓自己變成自大狂。

28． 使用“ 一千英尺高” 的視圖 （ Erik Doernenburg ）

選擇合適的架構視圖。

29． 先嘗試後決策 （ Erik Doernenburg ）

30． 掌握業務領域知識 （ Mark Richards ）

31． 程式設計是一種設計 （ Einar Landre ）

軟體開發也分成設計和生產兩個階段。

32． 讓開發人員自己做主 （ Philip Nelson ）

33． 時間改變一切 （ Philip Nelson ）

選擇值得投入精力的工作，別跟以前的工作過不去。

34． 設立軟體架構專業為時尚早 （ Barry Hawkins ）

35． 控制項目規模 （ Dave Quick ）

36． 架構師不是演員，是管家 （ Barry Hawkins ）

別忘了你的工作責任。

37． 軟體架構的道德責任 （ Michael Nygard ）

架構師的決定會影響許多人，務必謹慎。

38． 摩天大廈不可伸縮 （ Michael Nygard ）

但軟體可以。

39． 混合開發的時代已經來臨 （ Edward Garson ）

40． 效能至上 （Craig Russell ）

41． 留意架構圖裡的空白地區 （ Michael Nygard ）

空白地區“充滿”了各種軟體和“硬體”。

42． 學習軟體專業的行話 （ Mark Richards ）

同行之間講行話方便交流。

43． 具體情境決定一切 （ Edward Garson ）

44． 侏儒、精靈、巫師和國王 （ Evan Cofsky ）

Team Dev不應該同質化。

45． 向建築師學習 （ Keith Braithwaite ）

借鑒建築行業的經驗。

46． 避免重複 （ Niclas Nilsson ）

47． 歡迎來到現實世界 （ Gregor Hohpe ）

現實世界比軟體世界複雜。

48． 仔細觀察，別試圖控制一切 （ Gregor Hohpe ）

49． 架構師好比兩面神 （ David Bartlett ）

架構師應該像兩面神一樣，眼觀六路、耳聽八方。

50． 架構師應關注邊界和介面  （ Einar Landre ）

尋找自然的邊界，分而治之。

51． 助力Team Dev （ Timothy High ）

優秀團隊是成功的保障，要盡量助力Team Dev。

52． 記錄決策理由 （ Timothy High ）

記錄架構決策背後的理由，具有極高的投資回報價值。

53． 挑戰假設, 尤其是你自己的 （ Timothy High   ）

臆斷是事情搞砸的主要根源。務必要確保軟體基石堅實可靠。

54． 分享知識和經驗 （ Paul W. Homer ）

協助周圍的人不斷改善，他們也會協助我們發揮出全部的潛力。

55． 模式病 （ Chad La Vigne ）

不要讓一展設計模式功力的慾望，遮蔽了務實的真知。

56． 不要濫用架構隱喻 （ David Ing ）

不要耽溺於系統隱喻之中，反讓它拖了後腿。

57． 關注應用程式的支援和維護 （ Mncedisi Kasper ）

應用程式的支援和維護，永遠都不應該是事後才考慮的事情。

58． 有舍才有得 （ Bill de hÓra ）

珍惜需要權衡的時機，遠勝毫無約束和限制。

59． 原則、公理和類比勝於個人意見和口味 （ Michael Harmer ）

60． 從“ 可行走骨架” 開始開發應用 （ Clint Shank ）

從“ 可行走骨架” 開始，增量培育系統成長 。

61． 資料是核心（ Paul W. Homer ）

從“資料是核心”這個角度去認識系統，能大大降低理解複雜度 。

62． 確保簡單問題有簡單的解 （Chad La Vigne ）

63． 架構師首先是開發人員 （Mike Brown ）

碰到麻煩時，架構師可不能只會幹吹煙圈卻束手無策。

64． 根據投資報酬率（ROI ）進行決策（ George Malamidis ）

65． 一切軟體系統都是遺留系統（ Dave Anderson ）

軟體很快便會過時，修改維護無可避免。

66． 起碼要有兩個可選解決方案（ Timothy High ）

67． 理解變化的影響 （ Doug Crawford ）

清楚認識變化類型及其影響。

68． 你不能不瞭解硬體（ Kamal Wickramanayake ）

硬體容量規劃，是和軟體架構同等重要的事情。

69． 現在走捷徑，將來需付息（ Scot Mcphee ）

及時還清技術債務。

70． 不要追求“完美”，“足夠好”就行（ Greg Nyberg ）

避免過度設計。

71． 小心“好主意” （ Greg Nyberg ）

72． 內容為王 （ Zubin Wadia ）

73． 對商業方，架構師要避免憤世嫉俗（ Chad La Vigne ）

74． 展開關鍵維度，發現設計中的不足（ Stephen Jones ）

75． 架構師要以自己的編程能力為依託（ Mike Brown ）

76． 命名要恰如其分（ Sam Gardiner ）

弄清楚要做的究竟是什麼。

77． 穩定的問題可以獲得高品質的解決方案（ Sam Gardiner ）

78． 天道酬勤（ Brian Hart ）

真正做好那些看似簡單的任務，堅守承諾。

79． 對決策負責（ Yi Zhou ）

80． 棄聰明，求質樸（ Eben Hewitt ）

81． 精心選擇有效技術，絕不輕易拋棄（ Chad La Vigne ）

82． 客戶的客戶才是你的客戶！（ Eben Hewitt ）

83． 事物發展總會出人意料 （ Peter Gillard-Moss ）

設計是在不斷變化的世界中持續進行探索實驗的過程。

84． 選擇彼此間能和諧共處的架構 （ Eric Hawthorne ）

當心“無所不能”型的架構。

85． 著重強調項目的商業價值（ Yi Zhou ）

86． 不僅僅只控制碼，也要控制資料 （ Chad La Vigne ）

87． 償還技術債務 （ Burkhardt Hufnagel ）

在速度和架構間進行權衡，保持平衡。

88． 不要急於求解（ Eben Hewitt ）

首先看看是否可以改變問題。

89． 打造稱手的系統（ Keith Braithwaite ）

90． 找到並留住富有激情的問題解決者 （ Chad La Vigne ）

91． 軟體並非真實的存在 （ Chad La Vigne ）

虛擬世界中的軟體是柔韌可變的。

92． 學習新語言 （ Burkhardt Hufnagel ）

防止溝通不暢和誤解 。

93． 沒有永不過時的解決方案（ Richard Monson-Haefel ）

94． 使用者接受度問題（ Norman Carnovale ）

減輕使用者接受度問題帶來的風險。

95． 清湯的重要啟示 （ Eben Hewitt ）

軟體架構設計需要不斷的精鍊濃縮。

96． 對終端使用者而言，介面就是系統 （ Vinayak Hegde ）

97． 優秀軟體不是構建出來的，而是培育起來的（ Bill de hÓra ）

這本書是開源的，大家可以到這裡查看書的所有原文內容：

http://97things.oreilly.com/wiki/index.php/97_Things_Every_Software_Architect_Should_Know_-_The_Book