12.18

为毛每篇文章都要加个标题？有时候在这个问题上就要纠结很久，索性还是以日期来的利索，好吧，我很龟毛- -

今天早上起来，无意去了某人的QZ，回忆起了些往事，然后走马观花的把所有日志都浏览了遍，真的只是浏览，主人的文笔太好，想看明白不是件容易的事情，总的来说，是人生中很重要的人之一。有时候希望自己能神经质一点，也发现生活中那些被忽视的细节，可惜我，始终是个没心没肺的人。

话说，今天的主题不是记流水账啊！T_T…上次在QZ马克了一下，起因是前一天晚上脑子里冒出很多想法，然后在第二天午睡的时候它们有发酵了一下，于是觉得应该记录下来。结果拖到今天才来写，我现在的拖延症究竟是有多么严重啊？！（究竟是没时间，还是没习惯…）

好了，发现写了3段还没如正题，我果然很龟毛……

时间：2011年12月14日晚

关键词：货币 价值 中央银行

时间：2011年12月15日中午

关键词：游戏世界 财富的产出 货币的流通 通货膨胀

时间：2011年12月15日晚

关键词：PVP 规则 常规 风险与机会 职业平衡 星杯传说

//==============================================================

再说下近来的一些经验和教训

主题是：如何避免bug的发生！

1. 坚决避免在2个地方做同样的事情！这是很多bug的源头，也是导致代码臃肿的主要原因，更关键在于它不会引导你去做一个好的设计，甚至是破坏原有的设计！！

2. 函数一定要尽量保证一个出口。以前不太理解工程中KGLOG_PROCESS_ERROR的设计初衷，保证只有一个出口，易于控制流程，易于测试，易于检测，易于避免内存泄露。

3. 对于能够拆分的函数一定要拆分，保证原子性，函数太多就拆文件。当然这条也有一个度，总之看你对总体设计的把握了，但一旦是因为偷懒或者以便利为缘由放在一起的都应当拆分。

4. 代码的可测试性的重要。这条其实与前面有点重复，但还是要单独拿出来讲，因为这个应该是很多程序员容易忽略的事情，起码以前我是这样。这样导致一个问题，每次你写出代码后会对自己的代码没有太大信心，为什么？因为你不能做到把所有情况都跑一遍。（因为做到这一点会花费你大量的时间，你会将这些时间用于取写新的代码或者优化原有的代码，而等到bug发生时再回头来改）但如果代码的可测试性好，就可以方便的写出单元测试函数，花个1,2小时甚至一个下午写单元测试案例将它们都跑一遍，这个时候你就可以很有信心的将它们交付给测试人员了^o^。而且在以后你要改动代码的时候，你会发现有一个自动单元测试文件的存在是一件多么美妙的事情！

5.既然提到了可测试性，那么如何提高它们呢？简单的来说，其实最终还是6个字——低耦合，高内聚，好吧我又废话了- -

低耦合：

a. 避免一个函数做多件事情

b. 不要将不相关的事情糅合到一起，仅仅因为它们在功能需求层面似乎是在一起的抑或是觉得这样用比较“方便”。

以游戏逻辑为例，逻辑的过程函数与数值规则函数就是一个可以拆分的，而过程函数中数据管理函数与逻辑函数又是可以拆分的，逻辑函数中又可以分为：回调函数（避免直接将功能函数做为回调），功能函数。功能函数继而再根据实际情况再细分。

c. 函数保证单出口的原则

高内聚：

a. 避免在一个功能在2个不同的地方调用，而它们通常不是那么直观。

b. 避免过度的函数拆分，该是原子操作的一定不能拆分。

c. 适度的文件拆分，按功能性划分拆分文件。

d. 避免全局变量的存在。