《遊戲程式設計模式》一1.1 什麼是軟體架構

本節書摘來異步社群《遊戲程式設計模式》一書中的第1章，第1.1節，作者： 【美】robert nystrom （尼斯卓姆） 譯者： 趙衛兵 , 許新星 , 姜召陽 , 陳侃 , 屈光輝 , 鄭炯彬 責編： 陳冀康，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

如果你從頭到尾閱讀了這本書，那麼你并不會了解到3d圖形背後的線性代數或者遊戲實體背後的演算。這本書也不會告訴你如何一步步改進你的ai搜尋樹或者模拟音頻播放中的房間混響。

哇，此段簡直為這本書打了一個糟糕的廣告。

相反，這本書是關于上面這一切要使用的代碼的組織方式。這裡少談代碼，多談代碼組織。每個程式都具有一定的組織性，即使它隻是“把所有東西扔到main()函數裡然後看看會發生什麼”，是以我認為讨論如何形成好的組織性會更有趣些。我們如何分辨一個架構的好壞呢？

我大概有5年時間一直在思索這個問題。當然，像你一樣，我對好的設計有着一種直覺。我們都遇見過非常糟糕的代碼庫，最希望做的就是剔除它們，結束自己的痛苦。

不得不承認，我們大多數人隻接觸到一部分這樣的工作。

少數幸運兒有相反的經驗，他們有機會與設計精美的代碼共事。那種代碼庫，感覺就像在一個完美的豪華酒店裡站了很多禮賓在翹首等待你的光臨。兩者之間有什麼差別呢？

對于我來說，好的設計意味着當我做出一個改動時，就好像整個程式都在期待它一樣。我可以調用少量可選的函數來完美地解決一個問題，而不會為軟體帶來副作用。

這聽起來不錯，但還不夠切實。“隻管寫你的代碼，架構會為你收拾一切。”沒錯!。

讓我解釋下。第一個關鍵部分是，架構意味着變化。人們不得不修改代碼庫。如果沒人接觸代碼（不管是因為代碼非常完美，又或者糟糕到人人都懶得打開文本編輯器來編輯它），那麼它的設計就是無法展現其意義的。衡量一個設計好壞的方法就是看它應對變化的靈活性。如果沒有變化，那麼這就像一個跑步者從來沒有離開過起跑線一樣。

在你打開編輯器添加新功能，修複bug或者由于其他原因要修改代碼之前，你必須要明白現有的代碼在做什麼。當然，你不必知道整個程式，但是你需要将所有相關的代碼加載到你的大腦中。

這在字面上是一個ocr1過程，不過這個想法有些奇怪。

我們傾向于略過這一步，但它往往是程式設計中最耗時的部分。如果你認為從磁盤加載一些資料到ram很慢的話，試着通過視覺神經将這些資料加載到你的大腦裡。

一旦你的大腦有了一個全面正确的認識，則隻需稍微思考一下就能提出解決方案。這觀點值得反複斟酌，但通常這是比較明确的。一旦你了解了這個問題和它涉及的代碼，則實際的編碼有時是微不足道的。

你的手指遊走于鍵盤間，直到右側的彩色燈光在螢幕上閃爍時，你就大功告成了，是嗎？還沒有！在你編寫測試，并将它發送給代碼審查之前，你通常有一些清理工作要做。

我說“測試”了嗎？哦，是的，我說了。為一些遊戲代碼編寫單元測試比較難，但是大部分代碼是可以完全測試的。

我這裡不是要慷慨陳詞，不過，如果你之前沒有考慮過多做自動化測試的話，我希望你多做一些。難道沒有比一遍一遍手動驗證東西更好的事情要做嗎？

你在遊戲中加入了一些代碼，但是你不想後面處理代碼的人花大量時間了解或修改你的代碼。除非變動很小，通常都會做些重新組織工作來讓你新加的代碼無縫內建到程式中。如果你做得很好，那麼下一個人在添加代碼的時候就不會察覺到你的代碼變動。

簡而言之，程式設計的流程圖如圖1-1所示。

現在想想，流程圖的環路中沒有出口有點小驚悚。

雖然不是很明顯，但我認為很多軟體架構師還處于學習階段。将代碼加載到腦中如此痛苦緩慢，得自己尋找政策來減少裝載代碼的體積。這本書有一整章（第5章）是關于解耦模式的，許多的設計模式也有相同的思想。

你可以用一堆方式來定義“解耦”，但我認為如果兩塊代碼耦合，意味着你必須同時了解這兩塊代碼。如果你讓它們解耦，那麼你隻需了解其一。這很棒，因為如果隻有一塊代碼和你的問題相關，則你隻需要将這塊代碼裝載到你的腦袋中，而不用把另外一塊也裝載進去。

對我來說，這是軟體架構的一個關鍵目标：在你前進前，最小化你腦海中的知識儲存量。

當然，對解耦的另一個定義就是當改變了一塊代碼時不必更改另外一塊代碼。很明顯，我們需要更改一些東西，但是耦合得越低，更改所波及的範圍就會越小。