这次去深圳大概办公至少四十天起，而且会很忙的那种，因为从八月初得知游戏要上微信，手Q，应用宝后，就开启加班比较猛的节奏。之前虽然也是996的模式，但是周末也可以休息一天，修了几次周六。但是大概从八月第三个礼拜开始，没有周末了，就是从早上十点上班，晚上十点半后下班，一周七天，出版本到十二点后。
中秋节加了三天班，国庆节加了六天班，留出一天调整下。九月初两个周末请假回家喝喜酒。有的同事连续上班五六十天。我老大是那种工作特别努力的那种，走的也很晚，真的不容易。在工作上是同事，是合作伙伴，把工作尽量做好，也多承担些，工作外希望是个朋友一样，可以聊聊一些八卦啥的。其实，大家都不容易，毕竟时间比较紧迫，加班有时候并不能保证质量，太累反而没有精力集中，适当的调整下。
虽然这边存在很多问题，早期提交代码各种不规范，提交的注释就是“bug修复”，也不知道修复了什么bug。提交代码前不在本地测试先，一启动就报错，包括策划提交的配置，当然这些都没问题。但是过了很长时间，还继续这样，包括快要上线，连配置都不正确，那么我可以理解为很可能没有测试过，对自己提交的配置没问题很自信。还有就是先前正确的功能后面就突然坏了，然后随便指定个人去看下其他同事曾经写的代码，或者早期负责该功能的同事，然后去翻着不熟悉的没有什么注释的大片代码，去找问题，才发现自己的代码没问题，其他代码被改动了，却没有回归测试，这样的情况经历了不知道多少次，索性这些问题修的时候还不难，只是比较蛋疼，需要去理解别人写的代码什么意思，怎么定位问题，怎么改。还有就是在不是自己写的功能上加个小需求，其实很简单，但是前提你得熟悉这块系统，比如任务系统，五六千行代码，注释很少，当时刚来这边就写个副本玩法，但不知道为什么设计成跟任务关联，再写个副本，用任务驱动副本，当时写的很蛋疼，后来几个自己负责的副本玩法脱离任务，包括当时用任务驱动的阻挡，后来被我拆开成两个接口就很清晰。
由于游戏行业比较特殊，多方面的协作，有客户端，服务端，美术，策划，所以很多次打版本，一直提交配置，代码和资源，导致漏提交，多提交，错提交，每次打一个版本需要近一个小时，出啥小问题需要重来，导致太多次到凌晨后才下班，就等着打版本成功才能下班，长期以往真的很累，心累。我对加班不反对，但反对长期无效加班，虽然坐那里等着，自己也没闲下来会看看代码，用工具扫描代码看有没有些问题，看下日志有没有出错，但真的看不动的时候就想先回去，但他们不走自己真的不好意思走。有可能到两三点版本好没有打好，不知道为啥每次都在出版本的时候提交一堆有潜在问题的代码或者配置资源，这些流程不改变，效率提不上来，隔天精力不好工作效率可能会下降。
虽然这些都经历过来了，不管项目后面怎么样，也不是能够决定的，希望能够保证系统稳定，少出bug，提交前多review自己的代码，或者有多余精力和时间帮同事看下。
这一周还是修bug，和优化玩家数据增量落地。之前优化的是五个全局数据落地模块，这几个比较好改些，而玩家那边有call，会挂起协程，如果处理的不好，就可能造成有数据没有及时保存。这边优化后的粒度是增量一分钟一次，全量十分钟一次，当然可以配置。保证增加出问题但全量可以正确落地。
为什么玩家数据增量落地不好改，前几天也在考虑合适的方案。一方面修改玩家数据的模块很多很多，取玩家的数据方式不统一，有Set方式，有引用方式，那么Set可以多加个函数去保持增量的方式是修改还是增加删除什么的，然后引用就不大好办。然后把有变化的key设置在一个map表中，有更新就设置，以最后一次操作为准，如果是删除则设置一个特殊标志比如nil。把这些key-value同步到路由agent那边，需要判断当前状态是不是在doing状态，这里不能简单的覆盖和append，需要用个back_buffer的方式，append到这里面，之后call回来后，再把状态重置为非doing状态，并判断back_buffer是否有数据，有的话保存到master_buffer并重置back_buffer。
这里需要分工，有增量同步数据时只是简单的append，做同步操作的由其他协程，完事后再操作一些状态和恢复。毕竟多协程可能会修改一些全局的数据和状态。后来花了大概一小时把代码写完跑两天没啥问题，该落地的落地。这样没有必要全量落地，且粗粒度的去做事儿。
其实这块设计还是联想到redis中给从机同步数据是时的方案。
还有两个更严重的问题，一个是采集cpu数据时出现毛刺的现象，还有个是一些玩法会出现卡顿，机看到的人和怪都不动，过几秒就继续。第一个问题还是腾讯那边反馈的，给了采集数据图，但是不清楚采集的尺度如何，虽然开服活动瞬间有大批玩家进入可能导致新的场景创建，如果没有足够的备用场景resume的话，场景创建也有点慢，在lua中就是创建虚拟机还有就是那种同步数据落地，如果玩家在同一时间点进场景，有可能定时器到了集中同步数据，这也是个问题，后来在定时这块分散开来，对每个玩家，用配置的时间间隔加上一个随机秒数，同步这块暂时就做了这些。对于毛刺，观察采集图没有什么规律，看下时间点都是在比如八点，八点零五分，八点十分这样子，且下午开始比较明显，因为那时候是游戏活动集中点，也会有大量玩家在线，当然也可能跟内部系统定时器之类的遍历玩家或者怪物等情况，这块问题还是要再慢慢测试和观察。
第二个卡顿问题，是根据QA和玩家反馈会有短暂性卡顿，就是人物都静止，按钮没响应，然后看下cpu采集数据，并没有百分之百。之后查下日志，虽然跟相应玩法的场景出现过overload情况，即发往给该虚拟机的消息队列消息数量超过一定阀值才出现的，处理不过来，可能是工作线程在处理某个耗时较久的消息没有及时处理该消息队列消息，也可能该工作线程处理该消息队列的消息过久不能及时释放锁和把消息队列push到全局队列中，因为线程处理消息时，会摘下该消息队列不被调度。
后来自己在本地机器上上了三百个机器人压测，是没有发现问题。可能本地没有线上那种测试环境。
在这边差不多把整个服务端代码翻了一遍，有时间看下技能/buff/AI/寻路/状态机这些。我还是觉得模块之间清晰一些好，解偶，功能可以模块化，这样当主要负责人不在时，或者增加修改需求时，修改模块也比较容易些。关键地方打上info日志，日志内容需要有意义些。
最后，希望自己不管在哪，还是要对自己的工作认真负责，及时反馈和跟踪，凡事有交代，件件有着落，事事有回音。另外，多思考多学习，不希望后面会遗憾当初年轻的自己没有好好努力。
最近再看智能指针那一章节内容，发现这个用法在phxqueue中用的好频繁。
