标签：
记录一些由程序中的量的堆积所引起的质的变化的几个问题：
关于自动代码生成：
一些人手工写的代码中不会遇到的问题，在用代码生成工具生成时就可能发生。
比如之前就遇到过的一个：Lua 在一个函数里默认不能超过 200 个变量声明。
这个限制在程序员直接写代码时和没有限制一样。
因为，不会真有人在一个函数里声明 200 个变量的。
可是，如果是用程序写的工具做自动代码生成，比如，从其它的语言生成的中间数据格式转为 Lua 脚本，这个问题就发生了。
当时还奇怪呢，为什么小数据量时没有问题，当数据量超过一个限定生成的 Lua 代码就跑不过了。
不过， 这个问题也比较直白，修改起来也不算个事儿。
拆函数，用表来存变量就可以了。
关于配置程序：
程序的配置很复杂，我们给它写个配置程序。
配置程序后来发展的越来越像个程序了，也越来越复杂了。
配置程序也需要配置程序了，后来，又变得复杂了。
怎么办？一定是哪里有问题。
提炼需求，重新设计，浴火重生吧。
配置程序的配置程序
关于循环：
单个文件耗时很小，很多个文件时时间就很可观了。
之前遇到的处理文件时，测试中没有发现卡界面。
后来，文件数达到一定程度时，发展，界面明显卡顿。
文件越多越卡，界面如同死一般。
经查，发现，处理一个文件时，速度是非常的快，几乎都是在毫秒级完成。
可是当有几千个几万个文件都要操作时，时间有很可观了。
怎么办？放后台线程里。
关于反序列化：
XML 文件内容过多在反序列化时导致内存不足。
反序列化采用 DOM 建树的方式读取，这样会把所有的 XML 内容都读到内存里。
而内存是有限的，XML 的文件大小则是无限的。（C# 里）
怎么办？换一种反序化方法，不用一下子全读的。
比如用 XmlDocument 按 Node 解析，以降低内存使用。
或者分文件，把大文件分成很多个小文件。
关于时间：
当然，这里说得肯定不是千年虫。
说得是证书过期
开发中使用的测试证书，有效期一年。
怎么办？重新生成一下就好。
只是要记得证书的有效期，在过期前记得更换。
关于读写性能优化：
这个不遇到问题是也是感觉不到问题的存在的。
当读写是问题时，就不得不解决了。
怎么办？
减少读写的次数，加大每次读写的粒度。
放到后台线程处理。
关于守护程序：
守护程序如果出了问题了，变会变成杀手。
这个前几天从左耳朵耗子那里也看到过类似的例子。
守护程序的通信模块出了问题，一直认为被守护程序没有启动。
它一直在起进程，起来的进程又看有没有守护程序，，，
之后，很快，系统资源耗尽。
怎么办？小心啊，毕竟，被自家养的狗咬是一个让人很不爽的事情。
关于单元测试：
单元测试写得好，下班儿下得早，重构代码无烦恼，休息时间自己跑。
是的，单元测试的重要性无需多言。
但是单元测试别写得太复杂了，给单元测试写单元测试毕竟有点递归的感觉。
这里有个有意思的小案例。
很久之前（起码超过一年）写的单元测试，后来由于代码一直更新而被“废弃”。
某天由于代码改动提交后自动编译服务器给你反馈了一个问题。
起初以为是灵异事件，因为确定“废弃”的单元测试已经被关闭了。
而反馈的问题的标签就是单元测试，并且是一个挺大的问题。
经过仔细检查，发现在另一个地方犯了个小错，跑了一个脚本，自动打开一切。
“废弃”的单元测试代码在自动编译服务器跑了一年多了，默默地！！！
确保你相关的代码没有问题，而在此期间，你代码不知道改变了多少个版本（接口一直没变）！！！
那一刻，似乎感觉到了代码跳动着的脉搏！
关于算法：
写了一个很复杂的算法，递归，分支的层级较深。
能根据预定义的优先级规则进行相应的运算。
数据输入后基本上人工只能判断简单的用例。
用例稍微复杂一点儿人基本上就看不懂了。
反正最后只能依赖单元测试了。
这不是重点。
重点是，有一天，输入了两条不相容的规则。
结果呢？出现了一个随机的结果！
程序出错时还会打印一条调侃你的话！
那条打印我是放在永远不会执行的分支里的！
你能想象半夜十一点，办公室里只有一个人。
调程序出了一个随机结果，日志里出现一条调侃你的话么？
八月，北京，没有空调，冷。
楞了几秒，反应过来后先拔网线。
查日志一切正常。
平静下来后查代码，半个小时后，真相大白。
谁 TMD 在程序遇到不确定的分支时加的随机数！！？？
从此，再也不输出拟人的信息了。
凌晨下班儿时，交换机上一闪一闪的亮点似乎在嘲笑着：愚蠢的人类...
咦，等等，这是莫尔斯电码的...
标签：
原文地址：http://my.oschina.net/xhan/blog/497911
