《遊戲程式設計模式》一1.6 簡單性

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

最近，我覺得如果有任何方法來緩解這些限制，那便是簡單性了。在今天我所寫的代碼中，我非常努力地嘗試着編寫最幹淨、最直接的函數來解決問題。這種代碼在你閱讀之後，就會明白它究竟做了什麼，并且不敢想象還有其他可能的解決方案。

我緻力于保持資料結構和算法的正确性（在這個順序下），然後繼續往下做。我覺得如果我能保持簡單性，代碼量就會變少。這意味着更改代碼時，我的腦袋裡隻需裝載更少的代碼。

它通常運作速度快，因為根本就沒有那麼多的開銷，也沒有太多的代碼要執行（這當然并非總是如此，你可以在小部分代碼中進行很多的循環和遞歸）。

blaise pascal用了一句名言作為了一封信的結尾：“我會寫一封更簡短的信，但我沒有足夠的時間。” 另一種引用來自antoine de saint- exupery：“極臻完美，并非無以複加，而是簡無可減。” 言歸正傳，我注意到，每次我修改這本書的章節時，它都會變得更短。一些章節在完成時要比原來縮短20%。

但是，請注意，我并不是說簡單的代碼會花費較少的時間來編寫。你會覺得最終的總代碼量更少了，但是一個好的解決方案并不是更少的實際代碼量，而是對代碼的升華。

我們很少會遇到一個非常複雜的問題，用例反而有一大堆，例如，你想讓x在z的情況下執行y而在a的情況下執行w，以此類推。換句話說，是一個不同執行個體行為的長清單。

最省腦力的方法就是隻編寫一次測試用例。看一下新手程式員，這是他們經常做的：為每個需要記住的用例建構大量的條件邏輯。

在那裡面毫無優雅性，當程式有輸入或者編碼者稍微考慮得跟用例有些不一樣時，這種風格的代碼就最終會淪陷。當我們考慮優雅的解決方案時，浮現腦海中的就有一個：一小塊邏輯就能正确地處理一大片用例。

你會發現這有點像模式比對或解謎。它需要努力識破測試用例的分散點，以找到它們背後隐藏的秩序。當你把它解決時，會感覺很棒。