游戏编程模式：前言（架构，性能和游戏）(Part III)

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），不要浪费时间去美化它。摇滚明星们把旅馆的房间搞得一团糟，因为他们知道他们第二天就要结账离开了。

• 但是，最重要的是，如果你想要制作有乐趣的东西，那么就享受制作过程中的乐趣吧！