筆記
業務千變萬化，技術層出不窮，設計理念也是百花齊放，看起來似乎很難有一套通用的規范來適用所有的架構設計場景。
幾個共性的原則隱含其中，這就是：合適原則、簡單原則、演化原則。
合適原則宣言：“合適優于業界領先”。
-
腳踏實地”主要體現在下面幾個方面。
- 將軍難打無兵之仗。沒那么多人，卻想干那么多活，是失敗的第一個主要原因。
- 羅馬不是一天建成的。沒有那么多積累，卻想一步登天，是失敗的第二個主要原因。
- 冰山下面才是關鍵。更多的時候，業界領先的方案其實都是“逼”出來的！簡單來說，“業務”發展到一定階段，量變導致了質變，出現了新的問題，已有的方式已經不能應對這些問題，需要用一種新的方案來解決，通過創新和嘗試，才有了業界領先的方案。沒有那么卓越的業務場景，卻幻想靈光一閃成為天才，是失敗的第三個主要原因。
真正優秀的架構都是在企業當前人力、條件、業務等各種約束下設計出來的，能夠合理地將資源整合在一起并發揮出最大功效，并且能夠快速落地。
簡單原則宣言：“簡單優于復雜”。
無論是結構的復雜性，還是邏輯的復雜性，都會存在各種問題，所以架構設計時如果簡單的方案和復雜的方案都可以滿足需求，最好選擇簡單的方案。《UNIX 編程藝術》總結的 KISS（Keep It Simple, Stupid!）原則一樣適應于架構設計。
軟件領域的復雜性體現在兩個方面：1. 結構的復雜性。2. 邏輯的復雜性。
結構復雜的系統幾乎毫無例外具備兩個特點：組成復雜系統的組件數量更多；同時這些組件之間的關系也更加復雜。
組件越多，就越有可能其中某個組件出現故障，從而導致系統故障。
某個組件改動，會影響關聯的所有組件，這些被影響的組件同樣會繼續遞歸影響更多的組件。
定位一個復雜系統中的問題總是比簡單系統更加困難。首先是組件多，每個組件都有嫌疑，因此要逐一排查；其次組件間的關系復雜，有可能表現故障的組件并不是真正問題的根源。
邏輯復雜的組件，一個典型特征就是單個組件承擔了太多的功能。
邏輯復雜幾乎會導致軟件工程的每個環節都有問題。
演化原則宣言：“演化優于一步到位”。
- 對于建筑來說，永恒是主題；而對于軟件來說，變化才是主題。軟件架構需要根據業務的發展而不斷變化。
- 如果沒有把握“軟件架構需要根據業務發展不斷變化”這個本質，在做架構設計的時候就很容易陷入一個誤區：試圖一步到位設計一個軟件架構，期望不管業務如何變化，架構都穩如磐石。
- 軟件架構設計其實更加類似于大自然“設計”一個生物，通過演化讓生物適應環境，逐步變得更加強大。
- 軟件架構設計同樣是類似的過程：
- 首先，設計出來的架構要滿足當時的業務需要。
- 其次，架構要不斷地在實際應用過程中迭代，保留優秀的設計，修復有缺陷的設計，改正錯誤的設計，去掉無用的設計，使得架構逐漸完善。
- 第三，當業務發生變化時，架構要擴展、重構，甚至重寫；代碼也許會重寫，但有價值的經驗、教訓、邏輯、設計等（類似生物體內的基因）卻可以在新架構中延續。
- 架構師在進行架構設計時需要牢記這個原則，時刻提醒自己不要貪大求全，或者盲目照搬大公司的做法。應該認真分析當前業務的特點，明確業務面臨的主要問題，設計合理的架構，快速落地以滿足業務需要，然后在運行過程中不斷完善架構，不斷隨著業務演化架構。
理解與思考
- 印象比較深的一點是：軟件的主題是變化。在工作中也深有體會。雖然部門設置了一堆的流程來試圖減少需求的變化，很顯然沒起作用。我覺得開發在埋怨需求變化的同時，也要做好設計，擁抱變化。埋怨和消極應付不是長遠之計。
- 很久之前我也表達過類似的觀點：軟件的發展和自然界的進化更類似。
- 以后碰到需求，先做起來，不要過分的追求完美，不要因沒有理想的方案而踟躕不前。
- 軟件架構能力是在實踐中鍛煉起來的。以后學習，一定要注意應用，不能為學習而學習。
課后題
我講的這三條架構設計原則是否每次都要全部遵循？是否有優先級？談談你的理解，并說說為什么。
這三條原則，我理解其實是講的一件事情，即：做架構設計的時候，以滿足當前業務需要為目標，保留演化和發展的能力，不好高騖遠，貪多求全。所以做設計的時候，應該都遵守。
