架構、性能、游戲

• 在開始讀第一章的時候會覺得有點混亂，作者提出了什么是架構這個問題，但是并沒有像其它書里那樣給出一個明確的定義，而是提到了：

  這本書是關于上面這一切要使用的代碼的組織方式。這里少談代碼，多談代碼組織。

• 仔細品讀這句話，你會發現這里面其實已經提到了什么是架構：所謂架構就是代碼的組織方式。但是從我個人的認識來看這并不夠全面，在這里在引用幾段《架構漫談》中的文字來闡述什么是架構：

  在每個人都必須自己完成所有生活必須品的生產的時候，是沒有架構
  的(當然在個人來講，同一時刻只能做有限的事情，在時間上還是可能會
  產生架構的)。一旦產生的分工，就把所有的事情，切分成由不同角色的什么是架構
  人來完成，最后再通過交易，使得每個個體都擁有生活必須品，而不需要
  每個個體做所有的事情，只需要每個個體做好自己擅長的事情，并具備一
  定的交易能力即可。

  這實際上就形成了社會的架構。那么怎么定義架構呢?以上面這個例
  子為例，把一個整體(完成人類生存的所有工作)切分成不同的部分(分 工)，由不同角色來完成這些分工，并通過建立不同部分相互溝通的機制， 使得這些部分能夠有機的結合為一個整體，并完成這個整體所需要的所有 活動，這就是架構。

  軟件架構實際上包括了:代碼架構， 以及承載代碼運行的硬件部署架構。實際上，硬件部署架構最終還是由代 碼的架構來決定。因為代碼架構不合理，是無法把一個運行單元分拆出多 個來的，那么硬件架構能分拆的就非常的有限，整個系統最終很難長的更大。

• 關于架構和性能的沖突，我認為這個點寫的很好，可以說我之前沒有這樣的認識。長久以來我都希望寫出非常面向對象的代碼，在我長久的認知中，代碼的靈活性、高擴展性和可維護性是最重要的，因此設計模式是我在編寫代碼時所追求的。

• 但是作者提出良好的架構是需要很大的代價的，因為這需要遵守一些列的準則，Coder必須謹慎的組織代碼，而且在引入了抽象，引入了可擴展性，引入的某個設計模式時，我們在增加了代碼的靈活性的同時也增加了不可讀性，增加了代碼復雜度，這就增加了理解的難度。過度的架構設計往往會導致代碼庫失控，也許你會看到接口和抽象無處不在，我們可能需要花費大量時間才能找到真正功能的代碼。關于這一點我也是深有體會，最近在看UniRx庫，發現各種接口齊飛，大量的重載，梳理起來確實很費勁。

• 同時，從代碼本身執行角度來說，靈活的代碼往往意味著執行速度比較慢。從UNITY的角度來說，因為有類似CLR的東西，當使用面向接口編程時，往往意味這具體類型的判斷需要在運行期，JIT做的越多，性能也越差。而且還很可能導致無法實現代碼緩存，每次運行都需要實時的做判定。

原型代碼

• 原型代碼中可能包含大量的一次性代碼，但是原型代碼往往意味著不可維護，必須被重寫。目前在項目的開發過程中，往往出現原型代碼被最終使用在項目中，簡直就是災難。

尋求平衡

• 快速編寫出的代碼未必是執行最快的代碼，而且這樣的代碼在后面往往需要花費很多時間來優化，這都是需要時間的。這些都需要平衡。

• 我們在工作中就是在不斷的尋找平衡，有時候看到自己寫的或者別人寫的代碼，就想去重構一下，但是現實又往往不給這個時間。