6、簡單性（Simplicity）

最近，我覺得如果有任何方法可以減輕這些限制條件的話，那麼就是簡單性。在我今天的代碼中，我做出了很大努力來寫解決問題的最幹淨的、最直接的代碼。就是那種你讀了之後，你準确地了解它所做的事情、并且想不出其他可能的解決方法的代碼。

我的目标是把資料結構和算法弄正确（大緻按照這個順序），然後從這兒開始。我發現，如果我保持事情的簡單性的話，那麼代碼的總量就會變得更少。那也就意味着在你需要變更代碼的時候，隻要将更少的代碼載入到大腦中就行了。

它（簡單的代碼）經常運作得更快，因為開銷變少了，要執行的代碼變少了。（當然事情并不總是這樣。你可以在一個短短的幾行代碼中打包很多的循環和遞歸。）

然而，注意我并不是說用來寫簡單代碼所花的時間就少。你可能會有這個錯誤的認識，畢竟最終你的代碼總量少了，但是一個好的解決方案不是代碼的增長（accretion），而是代碼的提煉（distillation）。

Blaise Pascal 因為這樣結束信件而著名：“我本可以寫一封更短的信的，但是我沒時間”。

另外一個可供選擇的引用案例來自Antoine de Saint-Exupery：“達到極緻（perfection）的時刻，不是在沒有什麼東西可以添加的時候，而是在沒有什麼東西可以拿走的時候。”

回到正題，我會告訴你們每次我修改本書的一章的時候，這一章就會變得更短。有幾章在它們完全寫好的時候被删減了20%。

我們很少面對一個優雅的問題。相反，我們遇到的是一堆使用情況（use cases）。你希望X當條件Z成立的時候做Y，但是當條件A成立的時候做W，等等。換句話說，不同案例行為的一個長長的清單。

花費最少腦力的解決方法就是直接一次性為這些使用情況寫代碼。如果你觀察新手程式員的話，這就是他們經常做的事：他們為自己頭腦中想到的每個情況churn out reams of conditional logic。

但是在這種解決方案裡沒有任何優雅的東西，并且這種風格的代碼在面對哪怕稍微不同于程式員所考慮過的例子的輸入時很容易失效。當我們想着優雅的解決方案時，我們經常在頭腦中出現的是一個通用的解決方案：很少的邏輯，但是仍然能夠正确地覆寫很大範圍的使用情況。

找到那樣的解決方案有點像是模式比對（pattern matching）或者是解謎。看穿零散的使用情況的例子以找到蘊含在其中的隐藏的秩序，這需要努力。當你搞定它的時候，你就會感覺很棒。

7、Get On With It, Already

幾乎所有人都會跳過介紹性的章節，是以我祝賀你一路走來。對于你的耐心我無以回報，但是我将給你一些小小的建議，希望能夠幫助到你：

抽象和解耦使得發展你的程式變得更加快捷和簡單，但是除非你确信相關的代碼需要這種靈活性，否則就不要浪費時間去做它。
在整個開發周期中考慮性能，并為性能而設計，但是除非是到了不能再晚的時候，否則不要做出那些将假設鎖定到你的代碼中的、底層的、太細節的（nitty-gritty）優化。

相信我，遊戲發售的兩個月前并不是你想要開始擔心那個小小的煩人的“遊戲運作的FPS隻有1”的問題的時候。

快速地行動以探索你遊戲的設計空間，但是不要快到留下一個爛攤子的程度。畢竟，你得跟它一起生活。
如果你要做挖溝代碼（If you are going to ditch code），不要浪費時間去美化它。搖滾明星們把旅館的房間搞得一團糟，因為他們知道他們第二天就要結賬離開了。
但是，最重要的是，如果你想要制作有樂趣的東西，那麼就享受制作過程中的樂趣吧！