軟件架構師應該知道的97件事
阿新 • • 發佈：2018-12-05
需求 創意 要求 編寫 訓練 簡單的 過去 演進 設計模式
5． 架構決定性能
種瓜得瓜，種豆得豆，架構設計也是一 樣道理。它是影響應用性能和可伸縮性的決定因素，性能參數是無法簡單地通過更換軟件，或者“調優”底層軟件架構來改善，必須遵循分布式計算和物理學的基本原理，必須在架構的設計（或重新設計）上投入更多精力。
6． 分析客戶需求背後的意義
抽絲剝繭，洞見癥結。不要被表面需求 迷惑。
7． 起立發言
讓溝通事半功倍，起立發言是最簡單、有效的方法。
8． 故障終究會發生
系統必然存在不同形式的故障隱患，無論如何都無法徹底消滅，應該提前設計預防措施，限制故障。
9． 我們常常忽略了自己在談判
工程師應該適時轉換角色，學習談判的 技巧。絕不能在與對方談判的第一個要求上就妥協讓步。
10． 量化需求
沒有規矩，不成方圓。在記錄需求的過程中，對一些模糊的描述比如“靈活”，“可維護性”，“性能”等通過簡單的問題來量化需求，比如“數量多少”，“有多頻繁”，“不能超過多長時間”等。如果缺乏客觀的標準，就只能任憑挑剔的用戶擺布。
11． 一行代碼比五百行架構說明更有價值
可工作的代碼才是目標，設計只是達成 目標手段。摩天大樓的建築師如果一味追求美觀而無視物理定律，遲早會自食其果。
12． 不存在放之四海皆準的解決方案
軟件世界沒有放之四海皆準的解決方案。架構師必須培養和訓練情境意識，才能更好地設計架構和解決問題。
13． 提前關註性能問題
盡早展開性能測試。尤其是對性能要求苛刻的系統，可以驗證架構和設計是否符合實際性能要求。
14． 架構設計要平衡兼顧多方需求
平衡兼顧項目的技術需求和相關各方的業務需求。
15． 草率提交任務是不負責任的行為 （ Niclas Nilsson ）
要設法杜絕開發人員草率提交任務的念頭。
16． 不要在一棵樹上吊死 （ Keith Braithwaite ）
為客戶提供多樣化的解決方案。
17． 業務目標至上 （ Dave Muirhead ）
技術決策不能脫離業務目標和現實條件的約束。
18． 先確保解決方案簡單可用，再考慮通用性和復用性 （ Kevlin Henney ）
如果存在多個可實施方案難以取舍，“先簡單後通用”原則可以成為最終的評判標準。通過經驗提練的簡單方案，遠勝過不切實際的通用性。
19． 架構師應該親歷親為 （ John Davies ）
身先士卒才能贏得同事的信任。
20． 持續集成 （ David Bartlett ）
持續集成確保當前的開發不會出現意外，借助它可以取得更穩定、更符合要求的開發成果。
21． 避免進度調整失誤 （ Norman Carnovale ）
不惜一切代價拒絕調整項目進度的要求。為提高交付速度而改變計劃會帶來一系列的問題。
22． 取舍的藝術 （ Mark Richards ）
架構不可能滿足所有需求。魚和熊掌不可兼得，應牢記瑞典和波蘭戰爭中瑞典瓦薩號（Vasa）戰艦的故事。
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 ）
開發團隊不應該同質化。軟件架構師好比國王，應該熟悉各種人的性格特點，招聘不同性格的人加入自己的團隊，為不同性格的團隊成員安排合適的任務，輕構化解各種難。由一幫性格相同的人設計的架構只能吸引同樣性格的人加入團隊，只能解決一類問題。
45． 向建築師學習 （ Keith Braithwaite ）
借鑒建築行業的經驗。架構師應該蘊含適當的藝術成分！
46． 避免重復 （ Niclas Nilsson ）
兩條公認的軟件開發的真理：
（1） 復制是魔鬼。
（2） 重復性的工作拖累開發進度。
消滅重復的內容是架構師的責任，為此應該重新研究框架，創造更完善的抽象機制，或者使用代碼生成器。
47． 歡迎來到現實世界 （ Gregor Hohpe ）
現實世界比軟件世界復雜。不要抱怨現實世界中用戶需求帶來的麻煩，不妨從中尋找解決問題的靈感。
48． 仔細觀察，別試圖控制一切 （ Gregor Hohpe ）
選擇合適的抽象層次能提供有效的信息，也方便用基本的驗證規則檢查模型，架構師應仔細觀察，提取模型，然後檢查驗證，別妄想掌控一切。
49． 架構師好比兩面神 （ David Bartlett ）
架構師應該像兩面神一樣，眼觀六路、耳聽八方。
50． 架構師應關註邊界和接口 （ Einar Landre ）
尋找自然的邊界，分而治之。架構師應關註和繪制“有界情境”和“情境地圖”，有界情境是用以唯一定義一個模型或概念的區域，通常以一朵雲或一個氣泡來表示。情境地圖則包含了一系列有界情境及它們之間的接口。
51． 助力開發團隊 （ Timothy High ）
優秀團隊是成功的保障，要盡量助力開發團隊。
52． 記錄決策理由 （ Timothy High ）
記錄架構決策背後的理由，長期有用，又無須為之付出過多精力維護，具有極高的投資回報價值。
53． 挑戰假設, 尤其是你自己的 （ Timothy High ）
臆斷是事情搞砸的主要根源。一定要拿出相關的經驗證據，仔細驗證假設，才能做出最終決策，務必要確保軟件基石堅實可靠。
54． 分享知識和經驗 （ Paul W. Homer ）
討論有助於發現不足，只有能非常容易地做出解釋，才表明你真正理解了。只有不斷解釋和討論，才能把經驗凝聚成知識。幫助周圍的人不斷改善，他們也會幫助我們發揮出全部的潛力。
55． 模式病 （ Chad La Vigne ）
不要讓一展設計模式功力的欲望，遮蔽了務實的真知。使用模式解決適用的問題才是最重要的。
56． 不要濫用架構隱喻 （ David Ing ）
不要耽溺於系統隱喻之中，只將之用於探索性的溝通，不要反讓它拖了後腿。
57． 關註應用程序的支持和維護 （ Mncedisi Kasper ）
應用程序的支持和維護，永遠都不應該是事後才考慮的事情。由於應用程序超過80%的生命周期都是在維護上，在設計時就應該多多關註支持和維護的問題。考慮生產環境修誤錯誤的壓力，生產環境中的日誌記錄級別要比開發環境中的低很多，考慮開發人員與支持人員具有不同的技能等。
58． 有舍才有得
珍惜需要權衡的時機，遠勝毫無約束和限制。
59． 原則、公理和類比勝於個人意見和口味 （ Michael Harmer ）
清楚的架構原則，能夠使那些不熟悉某項特別技術或組件的人，明白其中的緣由，更透徹地理解他們本不熟悉的技術。
60． 從“ 可行走骨架” 開始開發應用 （ Clint Shank ）
“可行走骨架”是對系統的最簡單實現，它貫穿頭尾，將所有主要的架構組件連接起來。從“ 可行走骨架” 開始，增量培育系統成長 。
61． 數據是核心（ Paul W. Homer ）
從“數據是核心”這個角度去認識系統，能大大降低理解復雜度 。
62． 確保簡單問題有簡單的解 （Chad La Vigne ）
試圖猜測未來的需求時，錯的概率是50%，錯得很離譜的概率是49%。今天只需要解決今天的問題就好。
把應用發布出去，從反饋中生成真實的需求。
63． 架構師首先是開發人員 （Mike Brown ）
碰到麻煩時，架構師可不能只會幹吹煙圈卻束手無策。獲得開發人員信任的最快捷方式：你的代碼就是你的資本。作為架構師，主要目標應該是創建可行、可維護的解決方案，當然，也一定要能夠解決當前的問題。
64． 根據投資回報率（ROI ）進行決策（ George Malamidis ）
在判斷每個決策選項是否務實或恰當時，將架構決策視為投資，並將相關的回報率也一並考慮在內。
65． 一切軟件系統都是遺留系統（ Dave Anderson ）
軟件很快便會過時，修改維護無可避免。需考慮以下幾點：
（1） 清晰性：各個組件和類的角色清晰。
（2） 可測性：系統易於驗證。
（3） 正確性：結果和設計或期望的一致。
（4） 可跟蹤：能迅速診斷出故障並立馬解決問題。
66． 起碼要有兩個可選解決方案（ Timothy High ）
軟件架構是要在所有給定的約束條件下，尋找到解決問題的最佳方案。期望第一個解決方案即滿足全部的需求和約束，幾乎是不可能的。如果對手頭的問題只有一個解決方案，這意味著將沒有進行折衷權衡的余地。這個唯一的解決方案可能無法令系統投資方滿意。
67． 理解變化的影響 （ Doug Crawford ）
清楚認識變化類型及其影響。變化有多種不同的表現形式：
（1） 功能需求的變化
（2） 可擴展性需求的演進
（3） 系統的接口被修改
（4） 團隊人員流動等。
管理變化並非架構師的職責，但架構師要確保變化是可控的，有許多工具和技術可以用以減輕變化的影響。
（1） 進行小規模的增量漸變。
（2） 構建可重復運行的測試用例，並經常運行。
（3） 讓測試用例更易編寫。
（4） 跟蹤好依賴關系。
（5） 系統性的行動，根據反饋信息作出進一步反應。
（6） 自動化重復的任務。
68． 你不能不了解硬件（ Kamal Wickramanayake ）
硬件容量規劃，是和軟件架構同等重要的事情。水平伸縮能力是關鍵，可以在需要時才添加硬件，而無須一開始就過量采購。
69． 現在走捷徑，將來需付息（ Scot Mcphee ）
及時還清技術債務。可能覺得單元測試並不直接產生價值，於是就讓開發人員跳過這些嚴格的測試工作，這將導致所交付的系統在未來更難修改，而且在修改時信心不足。 除了避免在開發初期走捷徑，發現有不當的設計決策時就要盡快修正，擱置越久，為之付出的利息也將越高。
70． 不要追求“完美”，“足夠好”就行（ Greg Nyberg ）
避免過度設計。不要屈服於企圖使設計或實現達到完美的誘惑。把目的設定在“足夠好”就行，當已經達成目標時，就停下來。
71． 小心“好主意” （ Greg Nyberg ）
“駱駝的鼻子”是 一個隱喻，指一旦允許一些不期望但很小的情況發生，後面就會招致巨大而無法避免的情況發生。“好主意”就如“駱駝的鼻子”，它將導致範圍膨脹，復雜度上升，竭力把和業務需求無關的東西塞入應用中，這純粹是浪費精力。
72． 內容為王 （ Zubin Wadia ）
內容即網絡，即界面。在聯系日益緊密的今日世界，內容質量很快成為了成敗的關鍵。優秀的內容指的是其內容之間互相關聯，而不是空洞割裂。系統的成功取決於其內容，在設計過程中，要對內容價值的評估給予足夠重視。
73． 對商業方，架構師要避免憤世嫉俗（ Chad La Vigne ）
過度自信，會讓你在業務領域頭破血流。不要讓自己成為憤世嫉俗的“天才”，總是以一副自作聰明，居高臨下的語調，力求證明公司當前的運營是多麽的糟糕不堪，以期觸動業務方。成為優秀架構師的秘訣之中有一個關鍵要素，那就是要對工作滿懷激情，但不要是那種帶著憤怒和火氣的“激情”。
74． 拉伸關鍵維度，發現設計中的不足（ Stephen Jones ）
單獨拉伸每個維度，然後綜合起來看待，便可暴露出那些隱藏於最初設計中的潛在限制與不足。架構師可以通過
拉伸關鍵維度，對解決方案進行校核：
（1） 了解基礎設施的規劃是否能夠應付增長的需求，圈出限制範圍。
（2） 確認在預期的吞吐量下，系統不但能在當天內及時完成全天的任務處理，同時具備峰值儲備，才能應
對“特別忙碌的日子”，才能在停電後“加班補上”.
（3） 對當前的數據訪問方案進行校核，確保其在系統伸縮擴展時依然有效。
（4） 確保在系統工作負載上升時，（如果需要）能夠以增加硬件和轉換處理路徑的方式進行系統的伸縮擴展。
（5） 數據量持續上升，導致數據必須在更多的基礎設施間進行分割時，要確保應用程序仍然可用。
75． 架構師要以自己的編程能力為依托（ Mike Brown ）
為項目設計架構時，對實現每個設計元素所需的工作量，要做到心中有數;如果以前曾開發過其中某種設計元素，那麽估算所需工作量將會容易得多。
76． 命名要恰如其分（ Sam Gardiner ）
弄清楚要做的究竟是什麽。設計就是要去實現各種意圖，例如，快速、廉價、靈活、而名字便是用來承載和傳達這些意圖的。
77． 穩定的問題可以獲得高質量的解決方案（ Sam Gardiner ）
架構師必須從整體上看待雜亂無章的數據、概念、數據和處理邏輯，架構師要能夠將它們作為整體看待，並將它們分解為更小的片段或塊。這些問題塊必須是穩定的，只要問題是穩定的，就可以創建出一個擁有穩定設計的系統。穩定的設計可以讓你集中精力，打造出高質量的應用程序。
78． 天道酬勤（ Brian Hart ）
勤奮體現在很多方面，但歸根結底是指具備堅強的毅力，並且對系統的每項任務和每個架構目標，都能投入足夠的精力。真正做好那些看似簡單的任務，堅守承諾。很多時候，不是能力不足導致項目的失敗，而是由於勤奮不夠，緊迫感不強。
79． 對決策負責（ Yi Zhou ）
有效的架構決策包含：
（1） 無論是以敏捷的形式還是傳統的形式做出架構決策，都必須對決策過程有充分的認識。
（2） 要定期對架構決策進行復審;對照檢查決策的實際效果和預期效果;
（3） 要貫徹架構決策，只有全程跟進實施過程，才能夠確保最到位地實現其設計意圖。
（4） 並有所謂的全能技術天才，可以將一些決策委托給相應問題域的專家。
80． 棄聰明，求質樸（ Eben Hewitt ）
別去理會什麽流行風潮，只有真正睿智的架構師才懂得如何保持質樸。在質樸的方案中，每個組件只做一件事。
81． 精心選擇有效技術，絕不輕易拋棄（ Chad La Vigne ）
架構師工作很大的一部分，是要選擇用以攻克難題的合適技術。精心選擇熟悉的武器，不到萬不得已絕不輕易拋棄它們。同時，以審慎的態度更新你的技術武器庫。
82． 客戶的客戶才是你的客戶！（ Eben Hewitt ）
假設你正在編寫一個電子商務應用程序，那麽該仔細考慮的應當是那些會在那個網站上購物的人的需求。
83． 事物發展總會出人意料 （ Peter Gillard-Moss ）
設計是在不斷變化的世界中持續進行探索試驗的過程。無論研究得多麽深入透徹，無論設計是如何深思熟慮，事情最後總會變得和你想的不一樣，我們會發現通常無法預知的新信息。
84． 選擇彼此間能和諧共處的框架 （ Eric Hawthorne ）
當心“無所不能”型的框架。系統應該由多個相互獨立的框架組成，其中每個框架都精專於各自的領域，但同時又非常簡潔、包容和靈活。
85． 著重強調項目的商業價值（ Yi Zhou ）
可通過下面五步，成功將架構提案打造為典型的商業項目：
（1） 形成價值陳述，用以說明組織的業務為何要采用某種特定的軟件架構，重點應放在說明其在提高生產力、改進業務效率方面的能力。
（2） 建立量化的度量標準，量化得越具體越到位，項目也將越具有說服力。
（3） 回過頭來關聯傳統商業的衡量方式，如果能將技術分析轉化為財務數據，則會更為完美。
（4） 知道該在哪裏停止。準備好一張路線圖，用以捕獲遠景目標，清楚地知道每一個裏程碑將帶來的商業價值。讓利益相關者自己決定在何處停止。
（5） 尋找恰當的時機，如果時機不對，可能仍然無法成功推銷你的點子。
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 ）
要抵制試圖設計出龐大完整的系統來“滿足甚或超出”已知需求的特性期望的想法，要有宏偉的遠景，
但不要有龐大的設計。設計盡可能小的系統，幫助成功交付，並推動它向宏偉遠景目標不斷演化。
---------------------
作者：簡單極致_李
來源：CSDN
原文：https://blog.csdn.net/lixiaopeng23/article/details/9997531
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！
1．客戶需求重於個人簡歷
客戶需求至上。為了自己的簡歷更炫而采用新技術是沽名釣譽，往往事與願違。
2． 簡化根本復雜性 ，消除偶發復雜性
根本復雜性指的是問題與生俱來的、無法避免的困難。偶發復雜性是人們解決根本復雜性的過程中衍生的。分析問題好比撥雲見月、水落石出。架構師的責任在於解決問題的根本復雜性，同時避免引入偶發復雜性。
3． 關鍵問題可能不是出在技術上
大多數項目是由人完成的，人才是項目成敗與否的基礎。學會尊重他人，給予團隊成員充分的信任，是聰明的架構師獲得成功必須掌握的核心技能。團隊同心，其利斷金。
4． 以溝通為中心，堅持簡明清晰的表達方式和開明的領導風格
溝通應當言簡意賅、詳略得當，別拖泥 帶水。
5． 架構決定性能
種瓜得瓜，種豆得豆，架構設計也是一 樣道理。它是影響應用性能和可伸縮性的決定因素，性能參數是無法簡單地通過更換軟件，或者“調優”底層軟件架構來改善，必須遵循分布式計算和物理學的基本原理，必須在架構的設計（或重新設計）上投入更多精力。
6． 分析客戶需求背後的意義
抽絲剝繭，洞見癥結。不要被表面需求 迷惑。
7． 起立發言
讓溝通事半功倍，起立發言是最簡單、有效的方法。
8． 故障終究會發生
系統必然存在不同形式的故障隱患，無論如何都無法徹底消滅，應該提前設計預防措施，限制故障。
9． 我們常常忽略了自己在談判
工程師應該適時轉換角色，學習談判的 技巧。絕不能在與對方談判的第一個要求上就妥協讓步。
10． 量化需求
沒有規矩，不成方圓。在記錄需求的過程中，對一些模糊的描述比如“靈活”，“可維護性”，“性能”等通過簡單的問題來量化需求，比如“數量多少”，“有多頻繁”，“不能超過多長時間”等。如果缺乏客觀的標準，就只能任憑挑剔的用戶擺布。
11． 一行代碼比五百行架構說明更有價值
可工作的代碼才是目標，設計只是達成 目標手段。摩天大樓的建築師如果一味追求美觀而無視物理定律，遲早會自食其果。
12． 不存在放之四海皆準的解決方案
軟件世界沒有放之四海皆準的解決方案。架構師必須培養和訓練情境意識，才能更好地設計架構和解決問題。
13． 提前關註性能問題
盡早展開性能測試。尤其是對性能要求苛刻的系統，可以驗證架構和設計是否符合實際性能要求。
14． 架構設計要平衡兼顧多方需求
平衡兼顧項目的技術需求和相關各方的業務需求。
15． 草率提交任務是不負責任的行為 （ Niclas Nilsson ）
要設法杜絕開發人員草率提交任務的念頭。
16． 不要在一棵樹上吊死 （ Keith Braithwaite ）
為客戶提供多樣化的解決方案。
17． 業務目標至上 （ Dave Muirhead ）
技術決策不能脫離業務目標和現實條件的約束。
18． 先確保解決方案簡單可用，再考慮通用性和復用性 （ Kevlin Henney ）
如果存在多個可實施方案難以取舍，“先簡單後通用”原則可以成為最終的評判標準。通過經驗提練的簡單方案，遠勝過不切實際的通用性。
19． 架構師應該親歷親為 （ John Davies ）
身先士卒才能贏得同事的信任。
20． 持續集成 （ David Bartlett ）
持續集成確保當前的開發不會出現意外，借助它可以取得更穩定、更符合要求的開發成果。
21． 避免進度調整失誤 （ Norman Carnovale ）
不惜一切代價拒絕調整項目進度的要求。為提高交付速度而改變計劃會帶來一系列的問題。
22． 取舍的藝術 （ Mark Richards ）
架構不可能滿足所有需求。魚和熊掌不可兼得，應牢記瑞典和波蘭戰爭中瑞典瓦薩號（Vasa）戰艦的故事。
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 ）
開發團隊不應該同質化。軟件架構師好比國王，應該熟悉各種人的性格特點，招聘不同性格的人加入自己的團隊，為不同性格的團隊成員安排合適的任務，輕構化解各種難。由一幫性格相同的人設計的架構只能吸引同樣性格的人加入團隊，只能解決一類問題。
45． 向建築師學習 （ Keith Braithwaite ）
借鑒建築行業的經驗。架構師應該蘊含適當的藝術成分！
46． 避免重復 （ Niclas Nilsson ）
兩條公認的軟件開發的真理：
（1） 復制是魔鬼。
（2） 重復性的工作拖累開發進度。
消滅重復的內容是架構師的責任，為此應該重新研究框架，創造更完善的抽象機制，或者使用代碼生成器。
47． 歡迎來到現實世界 （ Gregor Hohpe ）
現實世界比軟件世界復雜。不要抱怨現實世界中用戶需求帶來的麻煩，不妨從中尋找解決問題的靈感。
48． 仔細觀察，別試圖控制一切 （ Gregor Hohpe ）
選擇合適的抽象層次能提供有效的信息，也方便用基本的驗證規則檢查模型，架構師應仔細觀察，提取模型，然後檢查驗證，別妄想掌控一切。
49． 架構師好比兩面神 （ David Bartlett ）
架構師應該像兩面神一樣，眼觀六路、耳聽八方。
50． 架構師應關註邊界和接口 （ Einar Landre ）
尋找自然的邊界，分而治之。架構師應關註和繪制“有界情境”和“情境地圖”，有界情境是用以唯一定義一個模型或概念的區域，通常以一朵雲或一個氣泡來表示。情境地圖則包含了一系列有界情境及它們之間的接口。
51． 助力開發團隊 （ Timothy High ）
優秀團隊是成功的保障，要盡量助力開發團隊。
52． 記錄決策理由 （ Timothy High ）
記錄架構決策背後的理由，長期有用，又無須為之付出過多精力維護，具有極高的投資回報價值。
53． 挑戰假設, 尤其是你自己的 （ Timothy High ）
臆斷是事情搞砸的主要根源。一定要拿出相關的經驗證據，仔細驗證假設，才能做出最終決策，務必要確保軟件基石堅實可靠。
54． 分享知識和經驗 （ Paul W. Homer ）
討論有助於發現不足，只有能非常容易地做出解釋，才表明你真正理解了。只有不斷解釋和討論，才能把經驗凝聚成知識。幫助周圍的人不斷改善，他們也會幫助我們發揮出全部的潛力。
55． 模式病 （ Chad La Vigne ）
不要讓一展設計模式功力的欲望，遮蔽了務實的真知。使用模式解決適用的問題才是最重要的。
56． 不要濫用架構隱喻 （ David Ing ）
不要耽溺於系統隱喻之中，只將之用於探索性的溝通，不要反讓它拖了後腿。
57． 關註應用程序的支持和維護 （ Mncedisi Kasper ）
應用程序的支持和維護，永遠都不應該是事後才考慮的事情。由於應用程序超過80%的生命周期都是在維護上，在設計時就應該多多關註支持和維護的問題。考慮生產環境修誤錯誤的壓力，生產環境中的日誌記錄級別要比開發環境中的低很多，考慮開發人員與支持人員具有不同的技能等。
58． 有舍才有得
珍惜需要權衡的時機，遠勝毫無約束和限制。
59． 原則、公理和類比勝於個人意見和口味 （ Michael Harmer ）
清楚的架構原則，能夠使那些不熟悉某項特別技術或組件的人，明白其中的緣由，更透徹地理解他們本不熟悉的技術。
60． 從“ 可行走骨架” 開始開發應用 （ Clint Shank ）
“可行走骨架”是對系統的最簡單實現，它貫穿頭尾，將所有主要的架構組件連接起來。從“ 可行走骨架” 開始，增量培育系統成長 。
61． 數據是核心（ Paul W. Homer ）
從“數據是核心”這個角度去認識系統，能大大降低理解復雜度 。
62． 確保簡單問題有簡單的解 （Chad La Vigne ）
試圖猜測未來的需求時，錯的概率是50%，錯得很離譜的概率是49%。今天只需要解決今天的問題就好。
把應用發布出去，從反饋中生成真實的需求。
63． 架構師首先是開發人員 （Mike Brown ）
碰到麻煩時，架構師可不能只會幹吹煙圈卻束手無策。獲得開發人員信任的最快捷方式：你的代碼就是你的資本。作為架構師，主要目標應該是創建可行、可維護的解決方案，當然，也一定要能夠解決當前的問題。
64． 根據投資回報率（ROI ）進行決策（ George Malamidis ）
在判斷每個決策選項是否務實或恰當時，將架構決策視為投資，並將相關的回報率也一並考慮在內。
65． 一切軟件系統都是遺留系統（ Dave Anderson ）
軟件很快便會過時，修改維護無可避免。需考慮以下幾點：
（1） 清晰性：各個組件和類的角色清晰。
（2） 可測性：系統易於驗證。
（3） 正確性：結果和設計或期望的一致。
（4） 可跟蹤：能迅速診斷出故障並立馬解決問題。
66． 起碼要有兩個可選解決方案（ Timothy High ）
軟件架構是要在所有給定的約束條件下，尋找到解決問題的最佳方案。期望第一個解決方案即滿足全部的需求和約束，幾乎是不可能的。如果對手頭的問題只有一個解決方案，這意味著將沒有進行折衷權衡的余地。這個唯一的解決方案可能無法令系統投資方滿意。
67． 理解變化的影響 （ Doug Crawford ）
清楚認識變化類型及其影響。變化有多種不同的表現形式：
（1） 功能需求的變化
（2） 可擴展性需求的演進
（3） 系統的接口被修改
（4） 團隊人員流動等。
管理變化並非架構師的職責，但架構師要確保變化是可控的，有許多工具和技術可以用以減輕變化的影響。
（1） 進行小規模的增量漸變。
（2） 構建可重復運行的測試用例，並經常運行。
（3） 讓測試用例更易編寫。
（4） 跟蹤好依賴關系。
（5） 系統性的行動，根據反饋信息作出進一步反應。
（6） 自動化重復的任務。
68． 你不能不了解硬件（ Kamal Wickramanayake ）
硬件容量規劃，是和軟件架構同等重要的事情。水平伸縮能力是關鍵，可以在需要時才添加硬件，而無須一開始就過量采購。
69． 現在走捷徑，將來需付息（ Scot Mcphee ）
及時還清技術債務。可能覺得單元測試並不直接產生價值，於是就讓開發人員跳過這些嚴格的測試工作，這將導致所交付的系統在未來更難修改，而且在修改時信心不足。 除了避免在開發初期走捷徑，發現有不當的設計決策時就要盡快修正，擱置越久，為之付出的利息也將越高。
70． 不要追求“完美”，“足夠好”就行（ Greg Nyberg ）
避免過度設計。不要屈服於企圖使設計或實現達到完美的誘惑。把目的設定在“足夠好”就行，當已經達成目標時，就停下來。
71． 小心“好主意” （ Greg Nyberg ）
“駱駝的鼻子”是 一個隱喻，指一旦允許一些不期望但很小的情況發生，後面就會招致巨大而無法避免的情況發生。“好主意”就如“駱駝的鼻子”，它將導致範圍膨脹，復雜度上升，竭力把和業務需求無關的東西塞入應用中，這純粹是浪費精力。
72． 內容為王 （ Zubin Wadia ）
內容即網絡，即界面。在聯系日益緊密的今日世界，內容質量很快成為了成敗的關鍵。優秀的內容指的是其內容之間互相關聯，而不是空洞割裂。系統的成功取決於其內容，在設計過程中，要對內容價值的評估給予足夠重視。
73． 對商業方，架構師要避免憤世嫉俗（ Chad La Vigne ）
過度自信，會讓你在業務領域頭破血流。不要讓自己成為憤世嫉俗的“天才”，總是以一副自作聰明，居高臨下的語調，力求證明公司當前的運營是多麽的糟糕不堪，以期觸動業務方。成為優秀架構師的秘訣之中有一個關鍵要素，那就是要對工作滿懷激情，但不要是那種帶著憤怒和火氣的“激情”。
74． 拉伸關鍵維度，發現設計中的不足（ Stephen Jones ）
單獨拉伸每個維度，然後綜合起來看待，便可暴露出那些隱藏於最初設計中的潛在限制與不足。架構師可以通過
拉伸關鍵維度，對解決方案進行校核：
（1） 了解基礎設施的規劃是否能夠應付增長的需求，圈出限制範圍。
（2） 確認在預期的吞吐量下，系統不但能在當天內及時完成全天的任務處理，同時具備峰值儲備，才能應
對“特別忙碌的日子”，才能在停電後“加班補上”.
（3） 對當前的數據訪問方案進行校核，確保其在系統伸縮擴展時依然有效。
（4） 確保在系統工作負載上升時，（如果需要）能夠以增加硬件和轉換處理路徑的方式進行系統的伸縮擴展。
（5） 數據量持續上升，導致數據必須在更多的基礎設施間進行分割時，要確保應用程序仍然可用。
75． 架構師要以自己的編程能力為依托（ Mike Brown ）
為項目設計架構時，對實現每個設計元素所需的工作量，要做到心中有數;如果以前曾開發過其中某種設計元素，那麽估算所需工作量將會容易得多。
76． 命名要恰如其分（ Sam Gardiner ）
弄清楚要做的究竟是什麽。設計就是要去實現各種意圖，例如，快速、廉價、靈活、而名字便是用來承載和傳達這些意圖的。
77． 穩定的問題可以獲得高質量的解決方案（ Sam Gardiner ）
架構師必須從整體上看待雜亂無章的數據、概念、數據和處理邏輯，架構師要能夠將它們作為整體看待，並將它們分解為更小的片段或塊。這些問題塊必須是穩定的，只要問題是穩定的，就可以創建出一個擁有穩定設計的系統。穩定的設計可以讓你集中精力，打造出高質量的應用程序。
78． 天道酬勤（ Brian Hart ）
勤奮體現在很多方面，但歸根結底是指具備堅強的毅力，並且對系統的每項任務和每個架構目標，都能投入足夠的精力。真正做好那些看似簡單的任務，堅守承諾。很多時候，不是能力不足導致項目的失敗，而是由於勤奮不夠，緊迫感不強。
79． 對決策負責（ Yi Zhou ）
有效的架構決策包含：
（1） 無論是以敏捷的形式還是傳統的形式做出架構決策，都必須對決策過程有充分的認識。
（2） 要定期對架構決策進行復審;對照檢查決策的實際效果和預期效果;
（3） 要貫徹架構決策，只有全程跟進實施過程，才能夠確保最到位地實現其設計意圖。
（4） 並有所謂的全能技術天才，可以將一些決策委托給相應問題域的專家。
80． 棄聰明，求質樸（ Eben Hewitt ）
別去理會什麽流行風潮，只有真正睿智的架構師才懂得如何保持質樸。在質樸的方案中，每個組件只做一件事。
81． 精心選擇有效技術，絕不輕易拋棄（ Chad La Vigne ）
架構師工作很大的一部分，是要選擇用以攻克難題的合適技術。精心選擇熟悉的武器，不到萬不得已絕不輕易拋棄它們。同時，以審慎的態度更新你的技術武器庫。
82． 客戶的客戶才是你的客戶！（ Eben Hewitt ）
假設你正在編寫一個電子商務應用程序，那麽該仔細考慮的應當是那些會在那個網站上購物的人的需求。
83． 事物發展總會出人意料 （ Peter Gillard-Moss ）
設計是在不斷變化的世界中持續進行探索試驗的過程。無論研究得多麽深入透徹，無論設計是如何深思熟慮，事情最後總會變得和你想的不一樣，我們會發現通常無法預知的新信息。
84． 選擇彼此間能和諧共處的框架 （ Eric Hawthorne ）
當心“無所不能”型的框架。系統應該由多個相互獨立的框架組成，其中每個框架都精專於各自的領域，但同時又非常簡潔、包容和靈活。
85． 著重強調項目的商業價值（ Yi Zhou ）
可通過下面五步，成功將架構提案打造為典型的商業項目：
（1） 形成價值陳述，用以說明組織的業務為何要采用某種特定的軟件架構，重點應放在說明其在提高生產力、改進業務效率方面的能力。
（2） 建立量化的度量標準，量化得越具體越到位，項目也將越具有說服力。
（3） 回過頭來關聯傳統商業的衡量方式，如果能將技術分析轉化為財務數據，則會更為完美。
（4） 知道該在哪裏停止。準備好一張路線圖，用以捕獲遠景目標，清楚地知道每一個裏程碑將帶來的商業價值。讓利益相關者自己決定在何處停止。
（5） 尋找恰當的時機，如果時機不對，可能仍然無法成功推銷你的點子。
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 ）
要抵制試圖設計出龐大完整的系統來“滿足甚或超出”已知需求的特性期望的想法，要有宏偉的遠景，
但不要有龐大的設計。設計盡可能小的系統，幫助成功交付，並推動它向宏偉遠景目標不斷演化。
---------------------
作者：簡單極致_李
來源：CSDN
原文：https://blog.csdn.net/lixiaopeng23/article/details/9997531
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！
軟件架構師應該知道的97件事