前言
最近换了新工作，一下子从做分发工具跳去做游戏了，不管是从工作内容还是工作形式上来说相比以前还是有很大的不同的。其中学到很多东西，当然也得到很多教训。
从来这里之后就接手游戏里面活动系统，相当于是重新做了一套活动系统，刚开始做的时候感觉略微痛苦，由于不太熟悉游戏相关业务和逻辑知识，做出来的东西与实际需要的相差较大，这样也就导致做了一部分要返工。上线了之后出现过Bug也即是解决了，总得来说这份工作让我有了相比以前不同的收获。
学会说不
这是《程序员的职业修养》里面的一个Item，这本书我也只是大致看了一点，而且这个观点在《高效程序的修炼》中也有提到，而最让我感慨的是我对这个概念的理解太晚。活动系统上线了之后出了几次Bug，总结来看就是每次做了太多的东西上线，而且有好几次都是快做完了策划临时修改需求，我想也没有想就根据策划新开的需求进行修改，往往活动上线的时候时候紧急，这样也就造成了代码上不完善，不够细致，出问题那就是必然了。
- 根据需求预估工作量提前告知策划。
- 要根据时间和需求合理安排自己的工作，绝对不要做承诺范围之外的东西，只承诺自己可以保证的东西。
- 在承诺范围内要保证上线版本没有bug，首先就要在代码端保证这种问题。
- 保证明显没有问题，而测试只能保证没有明显问题。
预判需求
通常在正式文档出来之前，策划的需求仍然处于不确定的状态，这个时候不是要动手也不是要思考，而是合理预判需求的变更或者做其他的事情，提前做好应对措施。
- 预判需求的大致走向，在最终需求文档没有到手上时不要动手做。
- 在动手做需求的时候，首先要做的事情是思考，考虑如何实现需求，同时也应该思考如何应对策划以后对这个需求的修改，或者提前对所做的需求预留”后门”。
代码总结
实际上整理代码的过程就是一次代码总结。很多时候由于时间紧急做出来的东西不是最佳的解决方案，我们要做到自己的代码没有问题，代码上的整理和总结是必要的。总结的过程可以发现自己写的不完善的地方，可以发现更好解决方案甚至在一定程度上保持代码美观。
- 代码总结和整理是必要，提交上去的代码一定要是美观且对需求是“满足且不会影响其他模块”的。
代码审查
以前没有正经经历过代码审查，来这边之后开始有几次代码审查，在审查过程中都发现了问题，所以在代码完成之后本地测试没有问题之后应该让同事给自己的代码进行审查，在检查代码的过程中发现编写不合理的地方。
- 在完成需求之后一定要让同事审查自己的代码，不怕批评，而是怕自己代码在线上爆出Bug。
- 在编写代码之前要做十足的思考，尽可能以最佳的解决方案实现。
关于请教
请教的前提一定是经过思考之后不确定或者思考之后仍旧存在疑问的。
- 请教之前必须要先思考的，请教的目的不是解决，而是启发。
- 请教总是虚心的。