46.
避免重複
如果開發人員複製救命**中的內容，說明這部分還可以簡化，甚至全部提取出來。
消滅複製是架構師的責任，如果有重複，則應該重新研究框架，創造更完善的抽象機制。
47.
歡迎來到現實世界
現實世界是不可預知的，隨時都可能發生一些讓人預料不到的事情，如客戶撤消訂單，付款時間延誤等。
如果現實世界帶來了麻煩，不要怕，不要報怨，尋找解決辦法應對即可。
48.
仔細觀察，別試圖控制一切
我們已經進入了分布式、松耦合的時代，不要妄想掌控一切，這樣只會讓你設計出緊耦合、脆弱的方案。但是撒手不管也是危險的狀態。正確的做法是：仔細觀察，提取模型，然後檢查驗證。
49.
架構師好比兩面神
要有兼顧前後、過去與未來的能力。善於傾聽和觀察，思想開放，即要滿足當前需求，又要兼顧未來的發展規劃。即要讓系統易於訪問，又要保證系統安全；即要讓設計符合當前的業務流程，又要體現管理層對未來發展規劃的考慮。融合不同的思想和觀念，兼顧不同的設想和目標，才能開發出皆大歡喜的產品。
50.
架構師當聚焦於邊界和介面
分而治之，分離關注點。對架構師來說，困難在於找到設定邊界的自然之處所需要的介面。情景地圖為架構師提供了乙個強大的工具，使得他們可以聚焦於「哪些應該歸在一起，而哪些應該分開」，從而使他們能夠以一種可順暢溝通的方式，實施明智的分而治之。
51.
助力開發團隊
要在職責範圍內盡量去助力開發團隊，不能僅僅是只說不做。要確保開發人員擁有所需的技能，定期進行培訓、討論、實踐等。在選拔開發人員過程中，也盡量選擇那些熱衷於學習，有亮點的。當不違背軟體設計的總目標時，就讓開發人員自己做出決策。要保護好開發人員，避免讓他們捲入太多不重要的工作之中。
52.
記錄決策理由
記錄軟體架構決策理由的檔案，長期來看非常有用，因為架構不會經常變，所以也不用付出過多維護精力。
它一般會記錄如下基本問題：1. 我們做了什麼決策？2. 為什麼這樣決策？3. 還有哪些解決方案沒有採用？ 等等
用處：1.溝通工具2.移交專案給別人3.寫檔案也會迫使自己明確這樣決策的理由，有助於確保基礎是紮實穩固的。4.當相關條件變化時，需要重新決策時，這份文件是乙個不錯的起點。
53.
挑戰假設，尤其是你自己的
「臆斷是事情搞砸的根源」 --- 韋森「延期判決」法則
要對一些假設清楚明確，拿出相關的經驗資料驗證假設，最後再做出決策。事實和假設是構建軟體的兩大支柱。務必確保軟體的基石堅實可靠。
54.
分享知識和經驗
軟體行業還非常年輕，想要持續發展，則傳播經驗和知識是非常重要的。
在個人層面，也利於成長，能更好的理解和修正已知的知識和經驗。
55.
模式病
避免過度使用模式，適合的才是好的
56.
不要濫用架構隱喻
隱喻對那些通常比較抽象、複雜和變化移動的目標，提供了很好的具體媒介。無論是與其他隊員溝通，還是與終端使用者討論架構全域性，找到有形實物作為正要構建的東西的隱喻都是十分誘人的。這在開始的時候很有效，都使用一種語言，能讓大家感覺到正確的方向，不斷演化前進。但隱喻也容易被濫用。
濫用隱喻可能讓其他團隊成員沉溺於隱喻，且隱喻不能完全展現問題。如業務系統還在構想之中時，和方共享的是最樂觀的可能解讀，並沒有包括任何必要的約束等。
57.
關注應用程式的支援和維護
架構師大多出身於開發人員，而非系統管理員，所以很容易站在開發者的角度上來思考。所以設計出來的系統，會讓系統管理員遇到很多問題，導致很多新的問題。
要學會多角度考慮，盡早引入支援負責人，讓其參與規劃應用程式的支援。
58.
有捨才有得
cap定理：在分布式系統中通常期望的3個特性，即一致性、可用性和分割槽容錯性是無法同時獲得的。
永遠不要放棄質疑，因為架構設計的教條往往從根基上削弱了交付能力。權衡是不可避免的，並且接受一些權衡，往往能產生富有創造性和創新性的結果。
59.
先考慮原則、公理和模擬，再考慮個人意見和口味
用原則、公理和模擬來指導建立過程，有很多優點：
a)架構文件化更容易b)更容易交流與傳奇架構師的個人意見與經驗c)清晰的架構能把架構師解放出來 等
如果單憑個人經驗、意見和口味來盲目地建立架構，是無法獲得這些好處的。
原則和公理還能確保架構上的一致性。
60. 從「
可行走骨架
」開始開發應用
「可行走骨架」是對系統的最簡單實現，它貫串頭尾，將所有的主要的構架元件連線起來。然後小步的、增量式的，能不斷得到反饋向正確方向前進。
61.
資料是核心
從概念上看，資料要比**更加精練，也更好理解。即使對地最複雜的系統，從面向資料的視角，即通過底層資訊的結構整體看待系統，也可將系統縮減為細節的有形集合。資料在大多數問題中牌核心地位，業務領域問題經由資料蔓延到**中。只有資料真正構成了每個系統的核心。
62.
確保簡單問題有簡單的解
簡單問題使用簡單解，聽起來容易做起來難。架構師經常出於炫技心理，容易過度設計。架構師會從主觀的判斷或潛在不確定需求出發，產生調整解決方案的強烈衝動。不要試圖猜測未來的需求，錯的概率是50%，錯的離譜的概率是49%。不要從主觀猜測未來需求，而是從反饋中不斷生成真實的需求。
軟體架構師應該知道的97件事 筆記 一
1.客戶需求重於個人簡歷 不要為了學習新的知識或豐富自己的簡歷而選擇新技術解決問題，要盡量選擇切合實際的技術解決客戶的難題。腳踏實地的為客戶著想，選擇正確的方案可以降低專案的壓力，團隊工作起來更開心，客戶也會更滿意，從而你也會有更充裕的時間學習新的知識。2.簡化根本複雜性，消除偶發複雜性 根本複雜性...
讀《軟體架構師應該知道的97件事》有感
其實拿到博文視點 贈送的這本 軟體架構師應該知道的97件事 已經有一段時間了，可一直沒有時間去讀。在剛剛忙完乙個大專案之後，又有資料庫集群的架構需要調整。想想事情永遠是做不完的，再忙也不能把給自己充電的事情落下。還好，這是一本不需要有大段連續時間來讀的書，只要有一點點時間，就可以翻開書頁學幾件 應該...
軟體架構師應該知道的97件事之概括1 15
架構師是一種神秘的職位，據說每個架構師都有密不可傳的方法，當然我們不信，更多的是只可意會不可言傳。就是說了我們也不會懂，因為還每到 火候 所能做的就是，當我們到這種火候的時候我們能想起來曾經有過架構師這麼說過，然後我們就可以更自信的向前大步走.1 客戶需求重於個人簡歷 積累一批滿意的客戶，選擇切合實...