成就職業(yè)理想：九十七條架構師必知的事情
51CTO 發(fā)表于：11年06月29日 10:16 [轉載] 51CTO
41. Engineer in the whitespaces by Michael Nygard
【設計空白處】
架構圖通常由一些方塊表示互相依賴的系統(tǒng)，它們之間用箭頭連接，箭頭邊上寫著小小的幾個字，剩下的就是大片的空白。這空白處看似什么都沒有，可是在現(xiàn)實中，有網卡、入侵檢測系統(tǒng)、防火墻、消息隊列服務、數(shù)據(jù)格式轉換服務、通信設備，甚至可能穿越萬水千山。因此，在這個箭頭旁，還是要把一些重要問題考慮清楚：
(1). 調用方操作太過頻繁怎么辦?忽略、禮貌地拒絕或者竭力滿足?
(2). 如果響應超時則調用方怎么辦?重試、等待或視為接收方故障?
(3). 雙方收到的數(shù)據(jù)版本或者格式與期待的不一致時怎么辦?
(4). 兩方中的任何一方短暫消失會有什么影響?
舉個例子，假設有個箭頭寫的是“HTTP搭載的SOAP-XML”，它可能會有這樣的注釋：“期待每個HTTP請求包含一條查詢，每個HTTP響應發(fā)回一條查詢結果。每秒最多接受100次請求，在99.999%比例下請求響應時間小于250毫秒”。
42. Talk the Talk by Mark Richards
【入行說行話】
專業(yè)人士之間常用行話交流，而架構師最重要的行話就是架構模式。模式可以按照層次范圍劃分為四類：企業(yè)架構模式、應用架構模式、集成模式、設計模式。企業(yè)架構模式處理高層架構，設計模式處理組件內部的架構。常見的企業(yè)架構模式有事件驅動架構(EDA)、面向服務架構(SOA)、面向資源架構 (ROA)以及管道架構(PA)。應用架構模式是企業(yè)架構內部應用或子系統(tǒng)架構的模式，例如J2EE中的會話面(Session Façade)、傳輸對象(Transfer Object)模式。集成模式是在應用、子系統(tǒng)、組件之間共享信息和功能的模式，比如文件共享、遠過程調用和各種消息收發(fā)模式。設計模式是最底層的模式，是架構師和開發(fā)人員交流的標準詞匯。還要了解反面模式(anti-patterns)，也就是那些反復出現(xiàn)、起負作用、需要避免的過程。常見的反面模式包括分析麻痹(Analysis Paralysis)、委員會設計(Design By Committee)、蘑菇房管理(Mushroom Management)、死亡征途(Death March)等。了解架構模式何以讓我們更清楚、簡潔、高效地溝通，所謂入行說行話(walk the walk and talk the talk)。
43. Heterogeneity Wins by Edward Garson
【異構取勝】
在分布式軟件系統(tǒng)中，通信協(xié)議已經發(fā)生了一個重要的演變，就是從二進制協(xié)議向文本協(xié)議轉變。文本協(xié)議，比如用于Web服務的XML/SOAP、表述性狀態(tài)轉移(REST)、原子資源(Atom)、可擴展消息傳遞及呈現(xiàn)協(xié)議(XMPP)，使得通信更為簡單靈活，系統(tǒng)的不同部分可以按照自己的需要選擇不同的編程語言，以便發(fā)揮最佳的效果。由此形成的異構系統(tǒng)，必將超越過去由單一語言主宰的系統(tǒng)。
44. Dwarves, Elves, Wizards, andKings by Evan Cofsky
【小矮人、精靈、巫師和國王】
RandyWaterhouse在《Cryptonomicon》中將他遇到的人分為四類，他們是：
小矮人(Dwarves)： 他們在黑暗的洞穴中辛勤勞動，制作出漂亮的物品。他們的手藝名揚四方，他們的力量改變著大地。
精靈(Elves)：他們溫文爾雅，終日創(chuàng)造美麗神奇的東西。他們天賦極高，能實現(xiàn)其他種族不可思議的東西。
巫師(wizards)：他們精通魔法，無比強大。
國王(Kings)： 他們是領袖，知道如何調遣其他角色。
架構師好比是國王，該熟悉各個角色，還要保證所設計的架構中具有這些角色的位置。只為個別角色設計架構，就只能吸引個別的角色，不能發(fā)揮大家的特長。一個好國王，會給大家樹立追求的愿景，會讓大家各司其責，共同學習，共同成長，實現(xiàn)目標。
45. Learn from Architects ofBuildings by Keith Braithwaite
【向建筑師學習】
“建筑是一種社會行為，是人類活動的物質場所。”—Spiro Kostof
(在建筑中要充分考慮人和社會的因素)
“良好的教育和豐富的心靈也許能造就偉大的頭腦，卻不能造就偉大的建筑。”—Frank Lloyd Wright
(不斷嘗試和改進才能接近完美)
“醫(yī)生出了錯可以將死人埋掉，建筑師出了錯只能讓客戶種爬藤遮丑。”—ibid
(避免設計錯誤很重要)
“建筑師堅信，不僅要做上帝身邊的助手，還應該伺機取得上帝的寶座。”—Karen Moyer
(要立志精通客戶的業(yè)務)
“在建筑中和在一切操作藝術中一樣，最后都要歸于操作。操作的結果應當就是良好的建筑。好建筑有三個條件：有用、牢固、愉悅。”—Henry Watton
(好東西不經要有用、耐用，還要賞心悅目啊)
"建筑師一定是雕塑家或畫家。如果他不是雕塑家或畫家，他只能做個建筑工。"—John Ruskin
(美很重要)
"聽起來有點矛盾、但它的確是一個重要的真理：沒有哪個建筑能達到無瑕疵的崇高。"—ibid
(好作品也帶有作者和時代的局限性)
46. Fight repetition by NiclasNilsson
【消除重復】
軟件開發(fā)中有兩條真理：抄襲是作惡;重復勞動降低開發(fā)速度。如果一個項目的軟件大量存在復制、粘貼、修改的工作方式，或者不同地方都在處理驗證、審核、日志、數(shù)據(jù)持久化之類的工作，那么就有嚴重的重復問題。消除重復是架構師的職責。完全順序書寫的代碼只適合于給計算機執(zhí)行，良好的代碼是給人讀的，要讓人讀起來清楚、高效、輕松，那么就要消除重復性。使用恰當?shù)目蚣?包括面向方面編程框架)、對功能進行再抽象等，都是消除重復的方法。
47. .Welcome to the Real World byGregor Hohpe
【走進現(xiàn)實世界】
工程師喜歡精確，01世界的軟件工程師尤其喜歡按部就班的順序處理，喜歡是非分明�？墒乾F(xiàn)實世界卻是凌亂的�？蛻粝聠沃蠛芸煊忠∠�，支票被拒付，信件丟失，付款延期，承諾落空。用戶不按要求輸入數(shù)據(jù)，不按規(guī)定步驟操作。分布式系統(tǒng)帶來了更多的不一致性：服務連不通，不發(fā)通知就改接口，沒有事務保證�，F(xiàn)實就是這個樣子，早晚總會出問題，你得承認它。但也別太害怕。事件驅動編程、狀態(tài)機模式、錯誤重試等這些都是可以采用的技術。只是，在現(xiàn)實世界里，你要記�。盒前涂丝Х鹊瓴贿m用兩階段提交。
48. Don't Control, but Observe byGregor Hohpe
【寧觀察、不控制】
過去的系統(tǒng)比較簡單而固定，在架構上是實現(xiàn)設計模型，按模型控制構建過程。但是，21世紀的軟件開發(fā)中，在松耦合的基礎上對軟件提出了隨著時間演化的柔性(flexible)要求，因此就不再能夠嚴格控制。針對這種情況，可以先不用設計靜態(tài)的結構，而是在演化中持續(xù)觀察，從觀察所得到的數(shù)據(jù)中抽象出當時的模型，按照規(guī)則對模型進行驗證，保證它沒有循環(huán)依賴、空接收通道的消息發(fā)送等問題。
49. Janus the Architect by DaveBartlett
【向雅努斯學習】
雅努斯(Janus)是羅馬神話中的門神，他有兩個頭顱，守衛(wèi)著過去通向未來的大門。架構師要向雅努斯那樣，能傾聽客戶的訴求、分析他們的趨勢。他設計出來的架構既要滿足眼前的需要，又要適應即將到來的變革，經得起時間的考驗。
50. Architects focus is on theboundaries and interfaces by EinarLandre
【架構師關注邊界和接口】
處理復雜系統(tǒng)的基本策略是“分而治之、各個擊破”。架構師要將整個系統(tǒng)劃分成若干情景(Context)，各個情景有自己明確的邊界 (Boundary)，情景之間有組織歸屬、功能使用或者技術依賴關系，這些關系通過接口來具體實現(xiàn)。關注邊界和接口的結果，是形成低耦合、高內聚的系統(tǒng)。
51. Challenge assumptions -especially your own by Timothy High
【不要想當然】
因為assume(想當然)=ass(蠢驢) +u(你)+me(我)，所以想當然會使你我與蠢驢為伍。
沒有事實依據(jù)的道聽途說未必正確，沒有事實依據(jù)的主觀臆斷往往是錯的。即使正確的結論，也因時勢的變遷而發(fā)生改變。所以，在架構設計中，但凡要在幾種選項之間做出取舍的地方(比如性能與可維護性、成本與上市時間等)，都要提供選擇的理由。理由不能只是簡單的論斷，要有考查的要素(比如技術條件、人員技能、政策環(huán)境等)及其事實依據(jù)，。
52. Record your rationale by Timothy High
【記錄你的理由】
在作出技術取舍的時候，都要提供選擇的理由。提供理由的方式是把它記錄下來。要說明做了什么決定、選擇了什么、拒絕了什么，為何選這種而不選那種。這些文檔可以讓開發(fā)人員理解架構設計的內在邏輯、讓客戶理解為何某些部分要求更加昂貴的硬件設備、讓將來條件改變以后對系統(tǒng)架構進行修改更容易。
53. Empower developers by Timothy High
【培養(yǎng)開發(fā)人員】
架構師要盡力培養(yǎng)開發(fā)人員。為他們提供足夠的設備、網絡、數(shù)據(jù)、資料。保證他們具有所需的技能，不足的就要安排培訓。開發(fā)人員除了能動手實踐，還要參與學術討論，所以如果有出差經費的要讓組員參加各種宣講或會議，沒有經費的也要加入技術性的郵件列表并參與本地的一些活動。平庸的團隊不可能做出大事情，要盡可能參加選擇開發(fā)人員的過程，尋找那些對技術好學上進并且善于與團隊合作的人。在和軟件設計的大目標不沖突的地方，要讓開發(fā)人員自主決策。制定編碼原則、編碼規(guī)范。保護開發(fā)人員免受不必要的文字工作、辦公室雜務等打攪。架構師雖然不是項目經理，但在軟件開發(fā)過程方面要積極參與管理，消除各種障礙。
54. It is all about the data by Paul W. Homer
【軟件都跟數(shù)據(jù)有關】
一般討論編碼的時候，都是站在面向指令的視角，講命令、函數(shù)、算法�？墒且斫庖粋�復雜的系統(tǒng)(比如UNIX操作系統(tǒng))，就很難在成千上萬行代碼中理出頭緒。這時，如果我們關注代碼下面的數(shù)據(jù)(比如UNIX系統(tǒng)的文件、進程等)，就相對容易理解些了。形成這種對比的原因是代碼很龐雜，而數(shù)據(jù)則很簡潔。后者就是面向數(shù)據(jù)的視角。大多數(shù)問題的核心是數(shù)據(jù)問題。關注數(shù)據(jù)，能更容易地處理復雜系統(tǒng)問題。要在系統(tǒng)建設早期完整地設計數(shù)據(jù)結構，避免在系統(tǒng)建設過程中或投入運行后再來修改數(shù)據(jù)結構。數(shù)據(jù)結構修改將導致大量的代碼修改。
55. Control the data, not just thecode by Chad LaVigne
【控制數(shù)據(jù)，而不只是代碼】
只有由代碼自動構建程序的工具是不夠的。手工或者編寫腳本來修改數(shù)據(jù)庫、添加數(shù)據(jù)不僅效率低下，而且容易出錯。自動構建工具不僅要考慮代碼的變化，還要考慮數(shù)據(jù)結構的變化，它們是不可分割的一個整體。
56. Don't Stretch The ArchitectureMetaphors by David Ing
【不要讓比喻誤導他人】
在描述抽象或新的設計時，架構師喜歡使用比喻�？墒�，比喻容易讓人誤解。比如，“一個游艇一樣的系統(tǒng)”，言者可能指的是池子里的小船，而聽者理解的是橫跨太平洋的豪華游輪。又比如，“一個文件柜”，言者只是想表示內容是按字母排列的，而聽者卻想的是文件柜有六個面、上面還嵌入了一個鐘表。只在開始的時候使用比喻，然后要迅速轉入精確的描述，不能停留在比喻上。
57. Focus on Application Supportand Maintenance by Mncedisi Kasper
【關注應用支持與維護】
很多架構師出身于開發(fā)人員，因此他們過多地關注開發(fā)階段而很少關注軟件系統(tǒng)運行以后的支持和維護階段。其實，一個軟件系統(tǒng)的生命周期中，支持維護階段超過80%以上的時間比例。所以，設計之初，就要關注支持維護。要注意，支持人員和開發(fā)人員不同，他們沒有IDE工具，沒有復雜的測試工具，也不能隨意關閉和啟動生產系統(tǒng)。系統(tǒng)要給他們提供足夠的問題跟蹤、審核、分析手段。只有系統(tǒng)管理員滿意了，才會大家都滿意。
58. Prepare to pick two by Bill dehOra
【學會三選二】
著名的Brewer猜想說：對于現(xiàn)代分布式應用系統(tǒng)來說，數(shù)據(jù)一致性(Consistency)、系統(tǒng)可用性(Availability)、服務規(guī)模可分區(qū)性(Partitioning)三個目標(合稱CAP)不可同時滿足，最多只能選擇兩個。
59. Prefer principles, axioms andanalogies to opinion and taste byMichael Harmer
【多用原則、公理和民意，少用觀點和偏好】
架構師個人的觀點和偏好需要結合項目的實際情況進行仔細分析、充分論證，才能作為架構設計的依據(jù)。而原則、公理和民意，相對可以直接地作為架構設計的依據(jù)。所以，要提高架構水平和提高效率，可以多用原則、公理和民意，少用個人的觀點和偏好。
