軟體架構師應該知道的97件事 筆記(四)

46.
避免重複
如果開發人員複製救命代碼中的內容，說明這部分還可以簡化，甚至全部提取出來。
消滅複製是架構師的責任，如果有重複，則應該重新研究架構，創造更完善的抽象機制。

47.
歡迎來到現實世界
現實世界是不可預知的，隨時都可能發生一些讓人預料不到的事情，如客戶撤消訂單，付款時間延誤等。
如果現實世界帶來了麻煩，不要怕，不要報怨，尋找解決辦法應對即可。

48.
仔細觀察，別試圖控制一切
我們已經進入了分布式、松耦合的時代，不要妄想掌控一切，這樣只會讓你設計出緊耦合、脆弱的方案。但是撒手不管也是危險的狀態。正確的做法是：仔細觀察，提模數型，然後檢查驗證。

49. 架構師好比兩面神
要有兼顧前後、過去與未來的能力。善於傾聽和觀察，思想開放，即要滿足當前需求，又要兼顧未來的發展規劃。即要讓系統易於訪問，又要保證系統安全；即要讓設計符合當前的商務程序，又要體現管理層對未來發展規劃的考慮。融合不同的思想和觀念，兼顧不同的設想和目標，才能開發出皆大歡喜的產品。

50. 架構師當聚焦於邊界和介面
分而治之，分離關注點。對架構師來說，困難在於找到設定邊界的自然之處所需要的介面。情景地圖為架構師提供了一個強大的工具，使得他們可以聚焦於“哪些應該歸在一起，而哪些應該分開”，從而使他們能夠以一種可順暢溝通的方式，實施明智的分而治之。

51. 助力Team Dev
要在職責範圍內盡量去助力Team Dev，不能僅僅是只說不做。要確保開發人員擁有所需的技能，定期進行培訓、討論、實踐等。在選拔開發人員過程中，也盡量選擇那些熱衷於學習，有亮點的。當不違背軟體設計的總目標時，就讓開發人員自己做出決策。要保護好開發人員，避免讓他們捲入太多不重要的工作之中。

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%。不要從主觀猜測未來需求，而是從反饋中不斷產生真實的需求。