收藏!架构师需要掌握的99条铁律
經常有人問我：我是多少年某某行業工作經驗，我現在是去創業公司做技術總監還是去大公司做架構師？我發現我都無法回答這個問題。因為多少年某某行業工作經驗，并不能解析為具有怎樣的知識結構和掌握的能力數量和深度，很難與相應的職位需求進行匹配對應。
比如，架構師，幾乎所有公司的架構師需求都不完全一樣。為什么呢？軟件架構師是 IT 行業里獨一無二的職業，既要精通軟件開發技術，又要掌握業務知識，還要周旋于公司不同部門之間，協調各種矛盾。
以下是有志于成為架構師或已經是軟件架構師的應該知道的 99 件事，如果都精通吃透，應用在日常工作中，百萬年薪工作不是夢。
1．??多去參加大會沙龍，跟成功的架構師探討案例、思維模式和前沿技術。
自己摸索和嘗試耗費很多時間，有時候需要廣交朋友，跟成功的架構師們一起討論、一起成長。捷徑是找到成功的架構師，一起探討，走成功者走過的路。
2．??簡化根本復雜性?，消除偶發復雜性
根本復雜性指的是問題與生俱來的、無法避免的困難。偶發復雜性是人們解決根本復雜性的過程中衍生的。分析問題好比撥云見月、水落石出。架構師的責任在于解決問題的根本復雜性，同時避免引入偶發復雜性。
3．??關鍵問題可能不是出在技術上
大多數項目是由人完成的，人才是項目成敗與否的基礎。學會尊重他人，給予團隊成員充分的信任，是聰明的架構師獲得成功必須掌握的核心技能。團隊同心，其利斷金。
4．??以溝通為中心，堅持簡明清晰的表達方式和開明的領導風格
溝通應當言簡意賅、詳略得當，別拖泥?帶水。
5．??架構決定性能
種瓜得瓜，種豆得豆，架構設計也是一樣道理。它是影響應用性能和可伸縮性的決定因素，性能參數是無法簡單地通過更換軟件，或者“調優”底層軟件架構來改善，必須遵循分布式計算和物理學的基本原理，必須在架構的設計（或重新設計）上投入更多精力。
6．??分析客戶需求背后的意義
抽絲剝繭，洞見癥結。不要被表面需求迷惑。
7．??起立發言
讓溝通事半功倍，起立發言是最簡單、有效的方法。
8．??故障終究會發生
系統必然存在不同形式的故障隱患，無論如何都無法徹底消滅，應該提前設計預防措施，限制故障。
9．??我們常常忽略了自己在談判?
工程師應該適時轉換角色，學習談判的技巧。絕不能在與對方談判的第一個要求上就妥協讓步。
10．?量化需求
沒有規矩，不成方圓。在記錄需求的過程中，對一些模糊的描述比如“靈活”，“可維護性”，“性能”等通過簡單的問題來量化需求，比如“數量多少”，“有多頻繁”，“不能超過多長時間”等。如果缺乏客觀的標準，就只能任憑挑剔的用戶擺布。
11．?一行代碼比五百行架構說明更有價值
可工作的代碼才是目標，設計只是達成目標手段。摩天大樓的建筑師如果一味追求美觀而無視物理定律，遲早會自食其果。
12．?不存在放之四海皆準的解決方案
軟件世界沒有放之四海皆準的解決方案。架構師必須培養和訓練情境意識，才能更好地設計架構和解決問題。
13．?提前關注性能問題
盡早展開性能測試。尤其是對性能要求苛刻的系統，可以驗證架構和設計是否符合實際性能要求。
14．?架構設計要平衡兼顧多方需求
平衡兼顧項目的技術需求和相關各方的業務需求。
15．?草率提交任務是不負責任的行為???（?Niclas?Nilsson?）
要設法杜絕開發人員草率提交任務的念頭。
16．?不要在一棵樹上吊死???（?Keith?Braithwaite?）
為客戶提供多樣化的解決方案。
17．?業務目標至上?（?Dave?Muirhead?）
技術決策不能脫離業務目標和現實條件的約束。
18．?先確保解決方案簡單可用，再考慮通用性和復用性?
如果存在多個可實施方案難以取舍，“先簡單后通用”原則可以成為最終的評判標準。通過經驗提練的簡單方案，遠勝過不切實際的通用性。
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?）
要抵制試圖設計出龐大完整的系統來“滿足甚或超出”已知需求的特性期望的想法，要有宏偉的遠景，
但不要有龐大的設計。設計盡可能小的系統，幫助成功交付，并推動它向宏偉遠景目標不斷演化。
98. ???客戶需求重于個人簡歷
客戶需求至上。為了自己的簡歷更炫而采用新技術是沽名釣譽，往往事與愿違。
99. ???多用書面方式總結架構師的思維模式，多講述和分享，提高溝通能力和影響力
架構師的溝通能力和影響力很重要，要利用大會和互聯網，把自己的思維模式和架構體系整理出來，提煉，并多講述。這樣可以不斷提高自己的總結能力，溝通能力和影響力，提高日常跟團隊的協作能力。
? ? ? ?本文轉自itwriter的“架構師大會：頂級架構師應該知道的99件事”，稍有改動。本文是針對中國架構師大會宣傳而寫，但是文章不乏很多架構師箴言和經驗，值得大家學習和研究。
申明：感謝原創作者的辛勤付出。本號轉載的文章均會在文中注明，若遇到版權問題請聯系我們處理！
Elasticsearch在線分享直播
﹀
﹀
﹀
劉征，Elastic 中國技術布道師
《DevOps Handbook》《The Site Reliability Workbook》譯者；精通DevOps/SRE/ITSM等理論體系和相關實踐等落地實現。致力于通過社區推廣開源Elastic Stack技術堆棧的應用，包括運維大數據分析平臺、云原生服務治理、APM全鏈路監控和AIOps等使用場景。
使用 Elastic Stack 監測 COVID-19 疫情爆發網絡研討會2020年4月8日15:00 線上分享
用實際應用場景探索 Kibana 的多種用法 ，構建自己的個性化儀表板，從公共數據源跟蹤全球各地的COVID-19疫情狀況。在本演示中，您將了解如何輕松地在Elasticsearch中索引任何類型的數據索引，使用采集節點對其進行數據轉換，然后使用Kibana 的可視化、儀表板和地圖對疫情現狀進行分析。
亮點：
Elastic在CNCF云原生交互場景中的位置
在Kubernetes上運行?Elastic?Stack
演示：如何使用 ECK 部署、防護和升級 Elasticsearch
Beats?中使用?autodiscover?監測動態工作負載的入門知識
在Kubernetes上掌握可觀測經驗
報名方式：識別圖片二維碼或閱讀原文報名
想要加入中生代直播群的小伙伴，請添加群助手大白的微信
申請備注（姓名+公司+技術方向）
總結
以上是生活随笔為你收集整理的收藏!架构师需要掌握的99条铁律的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： hdu - 4027 Can you a
- 下一篇： hdu - 2512 一卡通大冒险 （斯