游戏编程经验分享：打造KISS项目的六大要诀

GameRes游资网授权发布 零、 编程的核心困难的是什么？

复杂。编程是很复杂的工作，以至于作为一门工科显得很不严谨，只要运作不出问题就当做没问题。编程最核心的技巧是抽象和间接。

抽象是简化核心问题的功夫。为什么要抽象？主要原因是一方面代码是写给人看的，要符合语义；另一方面，人在一个层次上能同时处理的概念通常只有7，抽象恰恰就是在为这种符合人性的需求，对问题规模进行切割。抽象能够带来间接，间接能够隔离变化，间接能够控制依赖方向，间接能够提供扩展性等等的项目需求。

抽象要我们对已有的业务概念进行裁剪，做减法，需要我们加深理解业务；间接需要我们为项目增加能力，做加法，需要我们有一定的想象力。

一、 要去理解业务，业务理解深刻了，那么逻辑自然就清晰了，写框架不完全是技术问题

如果你之前从头到尾做过一款有一定规模的游戏，那么下一次再写就会很漂亮，不是技术牛了，而是对问题理解深了。就像单词背多了，英语句子总能看得懂。游戏框架，需要你对写过大量游戏进行共性提炼。举个例子，你很容易发现数据与显示分离的好处，并且设计出MVC模式。

二、 坚持单点真理，把真理自动推导到系统每一处

如同几何一样，我们可以定义最基础的公理，推论出一系列的有用的推理。这需要不懈的努力才能做到，其中一个编程中给力的工具就是元编程。它能够把这些变量推导到系统的每一处。比如你定义了一系列xml数据格式，那么每添加一份xml就不应该写具体的parser以及定义结构体，应该能够做到在业务中直接使用这些数据，parser过程自动化。比如UI拖了一个按钮，那么业务也不用写一行xx = getButton(“xx”)，而是应该直接用，获取按钮的过程自动化。比如定义了网络协议，那么封包的过程自动化。比如美术给了新的图片，应该命名与策划定义id一致，程序只管按照约定读取，不用知道有新的图片，不用配置一个id。把所有的中间环节砍掉，代码量、工作量都会少很多，这些工作往往复复，会乘很多倍，在时间上积累起来一定是个数字，最糟糕的是，前期没有把框架做好，那么业务的技术负债就会越来越深。语义的另一个方面就是代码写下来就是完备的，比如写了创建，那么通常都要写删除，先把系统考虑成能够独立存在的，那么自然就少依赖，少bug。

三、 重新思考面向对象

先把一个观点放在这里，强类型语言(C++、Java)的面向对象都是不完整的，或者说那根本就不是面向对象。指着他们说面向对象不行就像指着太监说天下的男人不行。真正能玩耍面向对象的语言应该是动态语言，鸭子类型让我们不需要折腾继承这套玩法来进行多态。在静态语言中，继承职责有两个，一个是复用，一个多态。继承应该只用来复用，而不应该做多态(这就是C++多继承邪恶的地方)。

从历史的角度来看，面向对象是好东西，它带来的变化如同过去代码的结构化编程一样：取消goto语句，用顺序、循环、分支替代，从而让代码统一易读。而面向对象则是对数据的结构化编程，让数据更加抽象，让大家操作数据的时候不用关心数据有什么字段，而且对象的思路也能帮助我们进行抽象，提升代码抽象层次，而且还让我们更容易进行思考。

四、提前构建好，胜于等待需求冲击。有些东西易放难收，前期就把抽象做起来

杀鸡用牛刀是没问题的。对于全局性的接口，要一开始就把接口打磨干净，信息传递完整，把简单的完整的信息留给用户。如果项目中扩散着各种因为这个接口导致的脏代码，想在后面再收，那就很痛苦了。一些东西确实需要提前想清楚。比如热更新的支持、性能指标、UI系统等等。

五、分层模式是最好的架构，每个层面实实在在地解决一些实际问题

分层的优点在于，依赖方向得到最好的控制，而且代码复用高、耦合低。每个层次有自己的核心问题，比如引擎这一层就是做一些业务无关的功能，比如渲染器、物理引擎。比如框架层就是为业务支撑的，着眼于开发效率。分层架构的另一个好处是增加人手分工也是很容易的事情。

一个好的框架，能让业务逻辑清晰简单的表达，让用户的每一行代码都在解决业务问题，而且还能让业务问题简化。

六、训练编程直觉，训练自己写出简短的符合语义的代码。每次都把代码写好，写得多了，能够做到下意识地把代码写漂亮。

程序设计就是语言设计 —-松本行弘

只知道要符合语义并不够，还要知道怎么才能做到。把平时的代码写好，写干净，多阅读优秀的项目架构，那么开发的时候，自然就会不断地进行重构，得到漂亮的架构。练习能够让我们不需要思考怎么做，而是思考怎么创造。也许你懂得保护模式就能开发操作系统，但是写得是否漂亮，能否把它写好写大又是另一回事。不断归纳总结进行高强度练习，时间长了，你很难说清楚为什么要这么写，但这么写就是好，而且逻辑清晰，符合语义。就像绘画大师一样，画画就是好看，但也很难说清楚为什么每个动作，每个因素的变化，都会有不同的行为，如此多的细节，不可能全部都说出来。我们写程序也是要看着各种因素的变化，随着需求、性能指标、历史包袱、人员分工因素等等的不同，会开发出不同的代码。而不是机械地跟着教条走，新手才这么做。在你不断地漂亮地、快速地完成需求，自信心也随之而来，正反馈不断循环。