1、逻辑和数据分离
到底什么是逻辑？什么是数据？其实没有一个划分的界限，只有划分的粒度大小。简单理解可以认为函数（function）就是逻辑，表（table）就是数据。那么逻辑和数据分离要做的事情，其实就是把函数和表分开。逻辑和数据分离的好处，光写成文字很难让人信服，我们可以根据几个例子来阐述逻辑数据分离的优势。
a) 修改数据时，逻辑可以不改。
来看一种比较简单的情况，这个接口是根据传入的武学的品质返回不同的值。之前的实现如下：

这里的逻辑和数据糅合在了一起，会导致代码冗长、阅读不便、维护困难，阅读不便的同时书写时 bug 率就会提高，间接还会引起效率问题。那么，我们来把这个代码进行一下优化：

抽出一个表叫品质表，然后把上文中品质ID的对应关系通过填在品质表的 '替代物品ID' 字段解决，逻辑代码减少。增加新品质的时候，只需要在表中加个表项，任何涉及到品质相关的逻辑代码都不需要修改。这个修改，把十几行代码优化成了两行，再写得极致一点只需要一行，我觉得没必要了。所以，代码并不是越长越好，短小精悍才是王道。
b) 过分拆分的函数。
都听过一句话，函数拆的越细越好。其实原话并不是这样的，函数调用是有消耗的，这个消耗虽然对于逻辑来说可以忽略不计，但是当逻辑套逻辑，层层嵌套时，函数的消耗可能在最里层，这时候就是乘法原则了。所以，函数的拆分还是不能过度。例如下面的代码：

一个 buff 一个函数，粗看函数调用逻辑基本一致，只是数据不同，除了没有做到数据和逻辑分离，还把函数拆的过细，后期维护也很不方便。如果是为了每个函数能够清晰的指定名字，写在数据里即可。修改如下：

c) 逻辑稍显复杂，但还是有迹可循。
逻辑很复杂，但是如果能够写成通用的，就能通过填表来复用逻辑，比如下面这段代码是无法复用的：

这段代码是根据传入的参数 int_params 掉落不同的物品。按照这种写法，线上维护困难、逻辑和数据耦合太紧密容易出 bug 、功能类似的没有抽离成数据导致代码冗余。基本没有复用的可能性。
我们可以分析一下，哪些是可变数据，哪些是固定逻辑，然后分类、建表，同时逻辑抽离。改完后如下：

首先，分析掉落数据只有金钱和物品，所以可以建立枚举 NEWBEE_LOOT_TYPE ，然后掉落物品有可能掉落一个，也有可能掉落多个，所以可以配成列表。并且掉落之前可能触发剧情，所以将是否触发剧情也配置在表项中。基本就能把逻辑和数据分开了。
除了能实现之前代码的功能，通过不同的数据还能实现之前代码没有实现的功能，这就是数据驱动逻辑。
d) 逻辑简单，数据量巨大。
实现随机一个地名的函数，未优化前的版本是这样的：

因为地名是个 local 的变量，每次调用函数都要生成一个大的 table，在 c 底层会有 malloc 内存分配的消耗。
优化方法是将地名表抽成数据表或者全局数据，每次调用函数不需要重新生成，实际测试下来，以上方法调用 10w 次的时间为 4.2 秒；抽成数据的形式，仅需 0.07 秒。60倍的效率优化，已经称得上是神级优化了。

2、逻辑的清晰性
逻辑的清晰与不清晰直接影响到看代码的人的心情，如果它觉得这个代码很恶心，blame 一下发现是你写的，那么可能会引发一场血案。所以我们需要尽量把代码写得清晰易懂，下面介绍几个优化方案：
a) 适当换行增加可读性
比如以下这段正涛提供的代码，是一个多重条件判断，优化前的实现如下：

修改完后，虽然逻辑复杂程度还是一样，但是起码可读性增加了不少，实现如下：

b) 重复逻辑
对于通用的逻辑，一定要写成接口。而且，需要有一些辅助的接口文件，让人一眼就能找到，方便调用者调用而不会去再实现一遍相同的逻辑。

3、逻辑的共性
为什么要提出共性的概念，因为任何事物都有共性，如果把共性提出来，可以减少很多工作量。举个最简单的例子，如果让你做两个门派：丐帮和华山，这两个门派的共性是什么？是否有可能用相同的代码，而通过不同的数据驱动，产生不同的逻辑？答案是一定的。通过寻找共性，精简代码，代码短小精悍是永恒的主题。
多思考，想完再写，可以让你减少 9/10 的代码量，代码量不是越多越牛逼。而是，你用 1行就能实现别人 10 行甚至 20 行才能写出的功能，这才是核心竞争力！

4、数据的聚合性
数据的聚合主要是指功能类似的数据尽量聚在一起，来看个例子：

o_misc 中定义了一堆数据，有一百多个，在做数据存储的时候很影响效率。数据定义直接导致写逻辑的时候产生各种 if else。
能够归到一类的尽量聚合到一起，比如同是聊天记录，可以只用一个 key （聊天记录），然后频道在聊天记录下层进行定义。例如：

5、数据的序列化和反序列化
序列化是将对象的状态信息转换为可以存储或传输的形式的过程，反序列化则是其逆过程。比如一个 table 转化成字符串，就是序列化，json、sproto、protobuff 都是比较常用的序列化库。游戏的存档其实就是先做了序列化，然后再把序列化完的二进制数据持久化（持久化即内存数据写到数据库）的过程。来看一段代码：

通过接口获取 '武学上限' 这个数据，发现没有则自行创建，然后再获取一遍。之所以获取不到是因为在 o_typdedef 中没有定义。o_typdedef 是为了数据做序列化准备的。所以需要有一个数据定义才能做这部分序列化的工作。所以，所有涉及到存盘的数据都需要在 o_typdedef 中定义数据的格式。
之所以要逻辑和数据分离，还有一点是为了进行序列化，序列化的一定是变的数据，即游戏运行一段时间后函数还是这个函数，只是数据发生了变化，所以我们序列化的其实是变了的这部分数据。把函数理解为逻辑，那么把需要变化的数据抽离出来，然后做序列化，进行持久化，就是存档的过程；而从磁盘上反持久化回来，再进行反序列化，得到的就是读档回来的数据了。

二、常量

1、幻数（magic number）
编码者在写一个数字的时候，当时明白是什么含义，但是别的程序员来看的时候可能很难理解；过了一段时间之后，自己都忘了这是什么，编码中应该尽量避免。
缺点：可读性差，修改起来不方便。而且如果大量地方用到同一个数，然后某次重构没有改全，就会引起不可预料的bug；如图所示，图中的 15 就是 magic number。设想一下，如果有100个文件用到这个“强化等级”，那一旦策划将最大等级改成20级，这个修改量可想而知。
改善：可以通过常量定义的方式修改，所有常量统一存在另一个文件中。

2、枚举
枚举实现的就是常量的作用，上节幻数中提到的就是枚举的一种类型。来看一段代码：

这里的品质直接用了中文字符串进行表示，如果日后上线要批量提升一个等级，所有的涉及到这个中文的都要修改。所以，需要抽出中间层，也就是枚举，让调用者直接用枚举，在枚举上自行定义。我们来改一下：

把数据逐步抽离后，逻辑代码最终变成了一行，这就是重构的美妙之处。

3、增加枚举类型时的可行性
游戏中有大量用到精通的地方，如果某天老板心血来潮加一条 XX精通，那么所有用到精通的地方都需要增加一条对 XX精通的处理，这个是程序设计的大忌，游戏中有大量如下图的代码：

引入枚举类型的好处是，每次在增加枚举类型时，完全不用动之前的逻辑，改善代码以后如下：

三、函数

1、函数命名的规则
命名应当直观且可拼读，可望文知意，标识符的长度应当符合 “min-length && max-information” 原则，采用英文单词或单词组合，英文单词不要复杂，但用词需准确，切忌使用汉语拼音命名（汉语允许写在注释里）。
2、函数越低层，效率要求越高
之前做性能测试的时候发现，很多函数虽然单次调用不到 1 毫秒，但是它实现在了背包的逻辑里，然后角色逻辑又引用背包逻辑，队友逻辑又引用角色逻辑，每次嵌套都是在上层多一个循环。总的下来，卡顿就这么出现了。所以如果你确保这个函数会被层层嵌套的时候，那么函数的效率一定要保证。
3、local 函数提高效率
local 变量是存放在 lua 的堆栈里面的是 array 操作，而全局变量是存放在 _G 中的 table 中，效率不及堆栈：

4、函数优化规则
有的函数开销比较大，而调用的频率很低，那么可以暂时不做优化；反之，有的函数开销较小，但是调用的频率很高，从如何降低调用频率以及减少函数开销两个角度去思考，然后定下优化方案。
5、函数的长短
函数太长会导致可读性差，容易出错，且查错困难。最好拆分成可以复用的小函数。当然，函数也不宜过短，过短的函数会徒增函数调用的消耗。
6、函数复用
类似的逻辑一定要抽成函数，方便调用。

7、函数调用注意事项
a) 避免重复调用
如果函数实现复杂，尽量避免重复调用，举个例子：

这里的函数 G.call('门派_赤刀门_赤刀下一级要求',o_item_道具) 被调用了三次，其实可以再第一次调用完毕就存到临时变量，后面只要直接根据临时变量的值进行判断即可，减少函数调用的消耗要从细节做起。修改后如下：

四、算法复杂度

1、键值对替代数组
数组是很常用的数据结构，游戏里到处会用到。比如存储玩家的成就，每次完成成就的时候判断成就是否在成就完成数组中，如果不在，则将它塞到数组尾部。以下是判断成就是否完成的实现：

这样的实现，最坏时间复杂度 O(n)。数组长度是2000，就要遍历 2000 次。如果在客户端只有自己在跑，影响不会很大，但是在服务器上，每个玩家都有这个逻辑，最坏情况是 2000 乘上同时玩家数，会造成服务器的阻塞。
lua 的 table 除了数组的功能，还能实现键值对，底层实现是哈希表。哈希表的插入、删除都是 O(1) 的。

2、减少遍历全表的逻辑
有些时候需要遍历整个物品表，筛选出符合条件的物品。当表非常大时，遍历非常耗 CPU。

我们可以在逻辑功能需要筛选某些物品时，把候选的物品 ID 填在数据表的字段里，然后再在候选的 ID 中进行筛选。

3、递归转迭代
递归的代码一般涉及到函数的系统调用栈，所以会比较耗，很多递归都能改成 while 迭代。来看一个求两个数的最大公约数的实现。任何简单的递归都能通过一定的方式转换成迭代，只不过需要引用一个栈的数据结构去做这件事情。

4、绝对不要实现 NP 问题
NP问题即没有多项式算法的问题，这种算法是穷举（例如有向图的深度优先搜索），很可能一辈子都跑不出结果。类似的实现还有随机一种情况，如果条件满足就跳出；条件不满足继续随机。总之，算法复杂度无法预估的算法都是耍流氓！！！

5、轮询次数控制
当函数轮询超过 100 次时需要加以关注；
当函数轮询超过 1000 次时需要思考算法可行性；
当函数轮询超过 10000 次时需要提高警惕，已经不是算法本身的问题了；
当函数轮询超过 100000 次时需要杀个程序员祭天；
6、为何如此美妙的代码

判断一个实例是否某个列表中的其中一个，这么写是完全没必要的。
首先，逻辑运算_或这个函数的参数是个大的 table，需要等 table 构建完毕才会执行函数逻辑，而逻辑或的运算是一个条件成功就返回了，那么这个构建 table 的开销浪费掉了。
再者，这里可以用一种很简单的方法，把满足条件的属性设置到 o_clan_门派本身，作为它的一个属性，这样就可以控制在表里了，代码逻辑也会很简单，如下：