想要成為一個(gè)合格的軟件架構(gòu)師必須知道的事情

      軟件架構(gòu)師是個(gè)讓人羨慕的職業(yè)，在市場經(jīng)濟(jì)成熟的國家，其薪酬已經(jīng)達(dá)到醫(yī)生、律師、注冊會(huì)計(jì)師、建筑設(shè)計(jì)師的水平。但是薪酬高低與職業(yè)成熟度沒有直接的關(guān)系。重賞之下必有勇夫，高薪往往造成培養(yǎng)機(jī)制不健全的行業(yè)出現(xiàn)暫時(shí)的良莠不齊。目前我們還沒有培養(yǎng)軟件架構(gòu)師的成熟機(jī)制，架構(gòu)師大多是程序員自學(xué)成材。程序員擅長和電腦打交道，卻不善于處理工作中的人際關(guān)系。然而經(jīng)驗(yàn)表明，除了技術(shù)特長，溝通協(xié)作的技巧、領(lǐng)導(dǎo)協(xié)調(diào)的能力、統(tǒng)籌取舍的經(jīng)驗(yàn)在指揮開發(fā)項(xiàng)目的過程中起著更重要的作用，而這些內(nèi)容在計(jì)算機(jī)學(xué)院的課本里壓根找不到。剛剛升任軟件架構(gòu)師的人，都有一段時(shí)間覺得茫然失措，因?yàn)橛刑喾羌夹g(shù)問題困擾著他們。

軟件架構(gòu)師是IT 行業(yè)里獨(dú)一無二的職業(yè)，既要精通軟件開發(fā)技術(shù)，又要掌握業(yè)務(wù)知識(shí)，還要周旋于公司不同部門之間，協(xié)調(diào)各種予盾。做到這些絕非易事， 博文視點(diǎn) 即將翻譯出版的新書《軟件架構(gòu)師應(yīng)該知道的97 件事》（97 Things Every Software Architect Should Know ）探討的就是這個(gè)主題。

本書的編輯Richard Monson-Haefel 是暢銷書《 Enterprise JavaBeans 》和《 Java 消息服務(wù) 》的作者。Richard 邀請五十多位杰出的軟件架構(gòu)師分享工作經(jīng)驗(yàn)和觀點(diǎn)，幫助讀者少走彎路。其中不乏大家熟悉的名字：《 卓有成效的程序員 》的作者 Neal Ford ，《 企業(yè)集成模式 》的作者Gregor Hohpe ，Servlets 和JSP 專家組和W3C RDF 工作組技術(shù)專家Bill de hóra ， 《 Web 應(yīng)用程序快速開發(fā) ： 使用TurboGears 》的作者M(jìn)ark Ramm ，《 Release It! 》的作者M(jìn)ichael Nygard ，《 軟件開發(fā)沉思錄 》的作者之一Rebecca Parsons 博士，活躍于Perl 社區(qū)的女架構(gòu)師Allison Randal ，《 Java SOA Cookbook 》的作者 Eben Hewitt ， 等等。

目前這本書已經(jīng)翻譯完成，博文視點(diǎn)正在緊張地進(jìn)行后期制作，計(jì)劃2010 年4 月下旬出版。以下是書中97 篇文章的主題和作者列表。我們盡可能收集了作者的博客地址或個(gè)人主頁，方便大家瀏覽參考。本書的豆瓣頁面 。

 軟件架構(gòu)師應(yīng)該知道的97件事：

1．  客戶需求重于個(gè)人簡歷 （ Nitin Borwankar ）

客戶需求至上。沽名釣譽(yù)，事與愿違。

2．  簡化根本復(fù)雜性 ，消除偶發(fā)復(fù)雜性 （ Neal Ford ）

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

3．  關(guān)鍵問題可能不是出在技術(shù)上 （ Mark Ramm ）

團(tuán)隊(duì)同心，其利斷金。

4．  以溝通為中心，堅(jiān)持簡明清晰的表達(dá)方式和開明的領(lǐng)導(dǎo)風(fēng)格 （ Mark Richards ）

溝通應(yīng)當(dāng)言簡意賅、詳略得當(dāng)，別拖泥帶水。

5．  架構(gòu)決定性能 （ Randy Stafford ）

種瓜得瓜，種豆得豆，架構(gòu)設(shè)計(jì)也是一樣道理。

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

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

7．  起立發(fā)言 （ Udi Dahan ）

起立發(fā)言效果更好。

8．  故障終究會(huì)發(fā)生 （ Michael Nygard ）

應(yīng)該提前設(shè)計(jì)預(yù)防措施，限制故障。

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

工程師應(yīng)該適時(shí)轉(zhuǎn)換角色，學(xué)習(xí)談判的技巧。

10． 量化需求 （ Keith Braithwaite ）

沒有規(guī)矩，不成方圓。

11． 一行代碼比五百行架構(gòu)說明更有價(jià)值 （ Allison Randal ）

可工作的代碼才是目標(biāo)，設(shè)計(jì)只是達(dá)成目標(biāo)手段。

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

軟件世界沒有***。

13． 提前關(guān)注性能問題 （ Rebecca Parsons ）

盡早展開性能測試。

14． 架構(gòu)設(shè)計(jì)要平衡兼顧多方需求 （ Randy Stafford ）

平衡兼顧項(xiàng)目的技術(shù)需求和相關(guān)各方的業(yè)務(wù)需求。

15． 草率提交任務(wù)是不負(fù)責(zé)任的行為   （ Niclas Nilsson ）

要設(shè)法杜絕開發(fā)人員草率提交任務(wù)的念頭。

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

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

17． 業(yè)務(wù)目標(biāo)至上 （ Dave Muirhead ）

技術(shù)決策不能脫離業(yè)務(wù)目標(biāo)和現(xiàn)實(shí)條件的約束。

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

19． 架構(gòu)師應(yīng)該親歷親為 （ John Davies ）

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

20． 持續(xù)集成 （ David Bartlett ）

21． 避免進(jìn)度調(diào)整失誤 （ Norman Carnovale ）

不惜一切代價(jià)拒絕調(diào)整項(xiàng)目進(jìn)度的要求。

22． 取舍的藝術(shù) （ Mark Richards ）

架構(gòu)不可能滿足所有需求。

23． 打造數(shù)據(jù)庫堡壘 （ Dan Chak ）

一開始就要定義好數(shù)據(jù)模型。

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

推遲決策，建設(shè)性地利用不確定性。

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

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

26． 讓大家學(xué)會(huì)復(fù)用 （ Jeremy Meyer ）

重復(fù)利用已有資源，首先要改變大家的觀念。

27． 架構(gòu)里沒有大寫的“I ” （ Dave Quick ）

變讓自己變成自大狂。

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

選擇合適的架構(gòu)視圖。

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

30． 掌握業(yè)務(wù)領(lǐng)域知識(shí) （ Mark Richards ）

31． 程序設(shè)計(jì)是一種設(shè)計(jì) （ Einar Landre ）

軟件開發(fā)也分成設(shè)計(jì)和生產(chǎn)兩個(gè)階段。

32． 讓開發(fā)人員自己做主 （ Philip Nelson ）

33． 時(shí)間改變一切 （ Philip Nelson ）

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

34． 設(shè)立軟件架構(gòu)專業(yè)為時(shí)尚早 （ Barry Hawkins ）

35． 控制項(xiàng)目規(guī)模 （ Dave Quick ）

36． 架構(gòu)師不是演員，是管家 （ Barry Hawkins ）

別忘了你的工作責(zé)任。

37． 軟件架構(gòu)的道德責(zé)任 （ Michael Nygard ）

架構(gòu)師的決定會(huì)影響許多人，務(wù)必慎重。

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

但軟件可以。

39． 混合開發(fā)的時(shí)代已經(jīng)來臨 （ Edward Garson ）

40． 性能至上 （Craig Russell ）

41． 留意架構(gòu)圖里的空白區(qū)域 （ Michael Nygard ）

空白區(qū)域“充滿”了各種軟件和“硬件”。

42． 學(xué)習(xí)軟件專業(yè)的行話 （ Mark Richards ）

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

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

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

開發(fā)團(tuán)隊(duì)不應(yīng)該同質(zhì)化。

45． 向建筑師學(xué)習(xí) （ Keith Braithwaite ）

借鑒建筑行業(yè)的經(jīng)驗(yàn)。

46． 避免重復(fù) （ Niclas Nilsson ）

47． 歡迎來到現(xiàn)實(shí)世界 （ Gregor Hohpe ）

現(xiàn)實(shí)世界比軟件世界復(fù)雜。

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

49． 架構(gòu)師好比兩面神 （ David Bartlett ）

架構(gòu)師應(yīng)該像兩面神一樣，眼觀六路、耳聽八方。

50． 架構(gòu)師應(yīng)關(guān)注邊界和接口  （ Einar Landre ）

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

51． 助力開發(fā)團(tuán)隊(duì) （ Timothy High ）

優(yōu)秀團(tuán)隊(duì)是成功的保障，要盡量助力開發(fā)團(tuán)隊(duì)。

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

記錄架構(gòu)決策背后的理由，具有極高的投資回報(bào)價(jià)值。

53． 挑戰(zhàn)假設(shè), 尤其是你自己的 （ Timothy High   ）

臆斷是事情搞砸的主要根源。務(wù)必要確保軟件基石堅(jiān)實(shí)可靠。

54． 分享知識(shí)和經(jīng)驗(yàn) （ Paul W. Homer ）

幫助周圍的人不斷改善，他們也會(huì)幫助我們發(fā)揮出全部的潛力。

55． 模式病 （ Chad La Vigne ）

不要讓一展設(shè)計(jì)模式功力的欲望，遮蔽了務(wù)實(shí)的真知。

56． 不要濫用架構(gòu)隱喻 （ David Ing ）

不要耽溺于系統(tǒng)隱喻之中，反讓它拖了后腿。

57． 關(guān)注應(yīng)用程序的支持和維護(hù) （ Mncedisi Kasper ）

應(yīng)用程序的支持和維護(hù)，永遠(yuǎn)都不應(yīng)該是事后才考慮的事情。

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

珍惜需要權(quán)衡的時(shí)機(jī)，遠(yuǎn)勝毫無約束和限制。

59． 原則、公理和類比勝于個(gè)人意見和口味（ Michael Harmer ）

60． 從“ 可行走骨架” 開始開發(fā)應(yīng)用 （ Clint Shank ）

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

61． 數(shù)據(jù)是核心（ Paul W. Homer ）

從“數(shù)據(jù)是核心”這個(gè)角度去認(rèn)識(shí)系統(tǒng)，能大大降低理解復(fù)雜度 。

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

63． 架構(gòu)師首先是開發(fā)人員 （Mike Brown ）

碰到麻煩時(shí)，架構(gòu)師可不能只會(huì)干吹煙圈卻束手無策。

64． 根據(jù)投資回報(bào)率（ROI ）進(jìn)行決策（ George Malamidis ）

65． 一切軟件系統(tǒng)都是遺留系統(tǒng)（ Dave Anderson ）

軟件很快便會(huì)過時(shí)，修改維護(hù)無可避免。

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

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

清楚認(rèn)識(shí)變化類型及其影響。

68． 你不能不了解硬件（ Kamal Wickramanayake ）

硬件容量規(guī)劃，是和軟件架構(gòu)同等重要的事情。

69． 現(xiàn)在走捷徑，將來需付息（ Scot Mcphee ）

及時(shí)還清技術(shù)債務(wù)。

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

避免過度設(shè)計(jì)。

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

72． 內(nèi)容為王 （ Zubin Wadia ）

73． 對(duì)商業(yè)方，架構(gòu)師要避免憤世嫉俗（ Chad La Vigne ）

74． 拉伸關(guān)鍵維度，發(fā)現(xiàn)設(shè)計(jì)中的不足（ Stephen Jones ）

75． 架構(gòu)師要以自己的編程能力為依托（ Mike Brown ）

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

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

77． 穩(wěn)定的問題可以獲得高質(zhì)量的解決方案（ Sam Gardiner ）

78． 天道酬勤（ Brian Hart ）

真正做好那些看似簡單的任務(wù)，堅(jiān)守承諾。

79． 對(duì)決策負(fù)責(zé)（ Yi Zhou ）

80． 棄聰明，求質(zhì)樸（ Eben Hewitt ）

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

82． 客戶的客戶才是你的客戶?。?Eben Hewitt ）

83． 事物發(fā)展總會(huì)出人意料 （ Peter Gillard-Moss ）

設(shè)計(jì)是在不斷變化的世界中持續(xù)進(jìn)行探索試驗(yàn)的過程。

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

當(dāng)心“無所不能”型的框架。

85． 著重強(qiáng)調(diào)項(xiàng)目的商業(yè)價(jià)值（ Yi Zhou ）

86． 不僅僅只控制代碼，也要控制數(shù)據(jù)（ Chad La Vigne ）

87． 償還技術(shù)債務(wù) （ Burkhardt Hufnagel ）

在速度和架構(gòu)間進(jìn)行權(quán)衡，保持平衡。

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

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

89． 打造稱手的系統(tǒng)（ Keith Braithwaite ）

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

91． 軟件并非真實(shí)的存在 （ Chad La Vigne ）

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

92． 學(xué)習(xí)新語言 （ Burkhardt Hufnagel ）

防止溝通不暢和誤解 。

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

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

減輕用戶接受度問題帶來的風(fēng)險(xiǎn)。

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

軟件架構(gòu)設(shè)計(jì)需要不斷的精煉濃縮。

96． 對(duì)最終用戶而言，界面就是系統(tǒng)（ Vinayak Hegde ）

97． 優(yōu)秀軟件不是構(gòu)建出來的，而是培育起來的（ Bill de hóra ）