两年总结

入职两年整，有一些感慨，也有一些成长，虽然之前断断续续记录过。

从入职这边开始，中途参与一款开发一半的游戏，虽然之前这款游戏开发有一段时间了，但差不多都是搞基础代码，后面很多实现都从服务器挪到客户端。明显，这么做是正确的，可能之前把大部分实现放服务器是有一定的原因吧。后来开发大概十几个新的需求和一些基础代码的优化。后来因为有另外一款带ip的项目立项，就开始那款游戏的开发，从零开始，这款项目就封包了，现在还是原来那样。

后来重新写了副本基础代码，这样只要策划配置文档，不需要开发新的代码或者少量几行代码就可以弄出新的副本玩法。之前的做法是每个副本都要写个文件代码，里面三四百行都差不多逻辑的代码，一个简单副本玩法就一个文件。目前基础副本玩法有剧情副本十多个，日常副本两个，组队副本五六个，VIP副本两三个，就几份代码加一些配置搞定。

后来做了十多个PVP/PVE这样的大型多人本地副本/跨服玩法，中间遇到好些坑，包括设计和框架上面的问题，还好都一起解决了。还有那些大大小小的基础系统。也单独解决了一些复杂的问题，就是偶现，不知道怎么出现的那种，造成数据不一致性或者系统oom等。有几次是表明这儿代码有问题就交给对方去解决，我觉得这样也挺好的，并不是自己不负责任，而是引导对方用自己的思路去解决，这期间可以一起探讨下各自的想法和比较。后来也经常在“开发问题总结”中添加一些技术要点，防止后来人再次踩前面人踩过的坑，和线上值的注意的bug排查文档，记录问题出现的原因，哪儿的代码，修复代码，和总结点，这样挺好的。

这款项目时间比较紧迫，给了deadline，然后那段时间真的很忙很累，每天下班很晚，周末加班，大概持续到十二月初样子，中途在深圳出差两个月左右。参与一款完整的游戏开发，上线，运营，和解决线上bug，以及遇到之前测试没有测出的问题，和各种疑难杂症，尤其是那种负载，单点，安全，偶现的问题，比如偶现的oom(一次情况是gm测试，cache miss导致大量请求都透传到db那边，而每次请求都拉取玩家较多的数据，导致出现oom，因为设计原因不合理导致的，还有次是优化框架，导致数据包请求资源没有释放导致量到一定程度后出现oom的)，偶现的coredump(这个问题直到后期才偶现三次，且在不同的服上以不同的方式coredump，打印栈信息是某个实现，coredump在了非法地址的读或者写，具体技术细节不再细说。因为加了一个新的需求，导致加速复现问题，后来老大排查到是开源框架的原因已修复并提pr，这段代码之前运行好久好久，线上大半年没出现过问题，所以当时coredump时还挺惊讶的)，流量超大导致卡顿，偶现的登陆卡顿等，还有基础代码以及开源框架的坑，真的很锻炼能力。分析和解决问题的能力，基本上把能踩的坑都一起踩了一遍。

因为使用多线程后，就不知道会遇见什么样的问题，包括协程，使用不当就会以极低的概率出现严重的oom和coredump，加快复现才能定位哪儿问题和对应的解决方案。线上代码崩溃很严重，造成这一段时间内的数据没有及时落地和补偿。

这期间做了一些优化工作，主要是做了预处理，缓存类似的功能，包括战斗pk那块，有些非常频繁的逻辑可以优化掉。由于历史代码原因，那些技能AI什么的都没有重写，这块改起来成本和风险略大，需要熟悉这块的同事重写。经过几次的优化，效果特别明显，一般有经验的人是能知道哪儿有热点，不过还是要借助工具去量化这块。包括cpu，内存，网络这块，尽量提升性能，承载更多的玩家一起战斗。

年后花了一段时间开发lua性能分析工具，结合lua源码，部分实现和开源框架，可以参考之前的文章记录。又开发了三四个新的pvp/pve玩法，很多人那种的，当然经过这个几个玩法，暴露出之前没有出现的隐患问题，和彻底优化了一波代码包括基础代码以及框架部分。别看玩法实现难度不大，但有些技术实现点是需要好好想想的，怎么节省通信消息大小，场景间的数据同步等问题。以及一些小需求的修改增加，包括多版本之间的工作量。剩下的是解决线上问题，反馈运维那边的问题，以及监控线上机器的性能，当然也是借助数据统计工具。

最近一两个月没有新的需求，转而负责解决几个版本的线上问题，其实有点想法，在排查问题和解答运维那边反馈过来玩家的问题时，需要查日志，但有些日志不够详细，要么在关键地方没有日志流水，要么记录的日志对于排查问题是次要信息，怎么记录日志也很重要。

对于发现线上的问题，我先确定下是什么问题，是偶现的还是必现的，然后在本地使用相同版本的代码测试一下，然后根据关键错误信息定位代码处，先看下能不能结合原作者的实现思路揣摩实现思路，尝试修改，并反馈给对方。虽然看别人的代码可能有点难受，要么缺少必要的注释，要么实现过于复杂，虽然自己也有的时候一个功能代码行数一两百行，但当时可能时间原因或者真的不好重构，暂时就这样了，虽然这样的代码可能会有隐患，测试不全。

我自己修复完后，是需要反馈到测试那边，我也需要在bug管理工具上详细写上bug的描述，出现原因及截图，复现方法，和修复后验证的点。虽然修改代码可能会引入其他问题，我自己有几次就这样的经历，但还是要说明测试覆盖的路径，正确结果是什么，虽然这样感觉我是QA，兼职嘛，主要还是开发。

有些时候，对于无法解决的或者没有好的方法时，也可以折中下用另外一种方法或许就彻底解决了，死磕某种方案没啥意义。如果不能在一开始选择到符合业务的合理实现，先把功能写对，符合需求，各模块间清晰，耦合度低，后面在压力测试时，再进行优化，发现热点时再选择合适的数据结构和算法。虽然这个过程可能需要重新测试以及引入其他可能的bug，更激进点可能改动某一块代码需要通知使用他的其他同事那就有点蛋疼，所以抽象也很重要，把影响限制在很小范围内。所以在改动前还是需要评估下风险和时间成本，有经验的可以在开始前，先列出一些可行方案并评估下，然后再开始设计数据结构，怎么实现等。

之前一直使用SVN，虽然个人提交代码时有时候会偶尔注释不够仔细，少合代码，或者本来一个单子一个提交变成两个单子提交一次，导致合到分支出问题，后来真的注意些，规范些。后来要走的路还很长，如何在保持深度的情况下再延伸广度是目前需要计划的，可能在外人看来做游戏不难，包括写需求和玩法，但如果真的参与进来，把游戏做好，也是需要一定的付出，还要能针对不合理处提出自己的看法，和可能造成的风险。