上周周版本更新后的三天，我基本上都在不断的做hotfix，原因是之前我对一个跨服战场老系统里的部分代码逻辑进行重构和优化，本意是可以大幅降低服务器的单点负载，均衡服务器压力；但是不成想却引出几个比较难追查的问题。到昨天新的周版本上线，目前这一波阵痛期才算已经过去。
首先是自我检讨的部分
对运行了好几年的代码进行重构，很大的风险在于不能彻底理解这段代码的主人当时的想法：他为什么要这么做？这段看似“愚蠢”的代码，是不是在避开什么陷阱？尤其是在这个程序员已经离开项目组的时候。对于这次优化，我想当然的以为，当时是因为底层没有提供相关的支持（确实没有），所以才遗留下这样一段低效的逻辑。所以当我给底层架构添加上相关支持以后，就大刀阔斧的直接进行改动了。其实，这段代码还隐含的避免了其他问题，这个问题在这次的风波中也是爆发的最集中的一个。
另外的一个问题是，这套系统中，有一小段代码，只在生产服务器（外服）运行，而在测试服务器（内服），是跳过的。这样做的本意是为了方便内服测试人员的工作，但是实际上导致了这段代码在内服永远测试不到。这里我想有两种解决方案：
- 架设一个完全类似于外服环境的测试服务器，用于最后上线前的测试。这种服务器我们其实是有一台的，基本环境都和外服一致，但是在这个内服/外服开关上，它还是属于内服的，这是由于项目架构中的一些其他因素决定的，无法改变。因此，需要第二种方法进行配合；
- 在内服/外服开关方面，进行多种粒度、层次的划分。有一部分的开关（应该很少），是必须严格对应正确的内服/外服，不能更改；但是，还有一部分的开关，可以直接开放权限让测试人员进行配置，以模拟外服环境。而上面出问题的这个开关，显然应该属于第二种情况：因为这个开关本来就是为了方便测试人员内服测试而存在的，当然应该给予测试人员修改的权限。
第二个部分我想探讨下这种优化要不要做
从程序员的角度来说，这种容易引发单点负载过高的代码逻辑始终都是一颗定时炸弹，而且影响用户体验（黑屏、掉线、卡场景），在知道原因以及能够进行修正的情况下，一定是想要去进行代码重构与优化的。但是从策划的角度来说，之前的代码逻辑一直能够跑通，目前也没有形成严重的问题，玩家也已经接受了这种体验上的损失，这个优化似乎就没有那么紧迫，只是在增加风险。
那么，怎么样能够尽量降低风险，缩短重构后“补锅”的阵痛期呢？
- 每一次代码重构，必然带来风险。这时如果有之前完整的测试用例的积累，以及一套自动化测试系统，就是很强有力的保障。在面向用户的体验方面，自动化测试似乎是种奢望（一种表现是否正常，没有直接自动化判定的可靠方式）。所以，测试用例的积累就很关键了。但是随着测试人员的流动，我们项目中成熟系统的测试用例散佚不少，这里需要整个测试部门构建一套标准制度，进行测试用例方面的文档积累与沉淀。
- 重构代码上线前想好PlanB。这也是我们这次做的不好的一点，可能是由于轻视了这次重构的复杂度，所以并没有做好一个完善的备选方案。不过好在大部分错误都处理的还算及时，没有影响到游戏的主要流程。
- 在查找bug源头的时候，我发现，一条信息完备、便于检索的log，对于快速定位问题实在是太重要太重要。这里有一个技巧：凡是需要写正则表达式才能grep出来的log，一般都不是一条“好”log。将这个规则推广到代码中，就是说变量与函数名的命名要有辨识度与区分度，如果on、at这种名字出现在代码中，请自行面壁思过五分钟。
最后的话
如果没有代码重构与优化，再优秀的团队，也难以避免代码“腐烂”。但是重构与优化，一定是会带来一定的风险的。我们能做的是在上线前，通过一套可靠的机制，尽量减少犯错误的几率；一旦出现问题，也通过一套可靠的机制与方案，尽量缩短阵痛期。
不多说了，后面还有一个陈年系统要重构，社会主义核心价值观保佑我吧~
推荐阅读：
Python最差实践
从string.strip()引起的一个bug说起
这些年，你写了多少行代码
转载请注明出处： blog.guoyb.com/2017/09/28/…。
欢迎使用微信扫描下方二维码，关注我的微信公众号TechTalking，技术·生活·思考：
后端技术小黑屋
