入职一年有余了。

收获

　　第一次参加实战项目，也是第一次参加多人协作的项目，感觉很新鲜。回头看，学校应该多开展这样的训练。多人协作跟个人开发最大的不同，是需要大量阅读他人的项目代码，在实现功能的时候，也需要不断的进行妥协。要阅读一个新项目的代码，从最初的版本 checkout 进行阅读往往是比较好的选择，可以比较清晰的看到项目的架构思想，把握模块开发的惯用法。另外，首先阅读核心工具库帮助很大，一是能够很清晰看到老大的功力（笑），二是对于阅读他人的新模块，尽快投入开发，能够有较大帮助。

　　在学校学习 python，我只是掌握了基本语法和少数几个库。来到公司后，基本把 python 自带的库都用过一次了。第一次理解了什么叫做 Battery-Included，python 果然强大。除了官方库外，项目里还用到一些优秀的第三方开源库，例如 Google 的 protobuf，还有 gevent 协程库，项目的前任老大也向开源社区贡献了两个包，little and shiny，很不错。我发现我真的很享受开源社区的开发工作。

　　参加实战项目后，第一次发现，操作系统和计算机网络里的内容，很多都涉及到了，恰好当年对这两门课最感兴趣，因此开发还算顺利。回想起来，这一年里干的龌龊事还是不少的 XD，比如说将数据库当消息总线，满足多进程通讯的需要；又比如利用内建的 rpc 机制做了个 bug 重重的两层包转发；再比如那个利用 Mysql 的 InnoDB 行锁实现的多进程锁。当年操作系统课上，对于纤程只是一带而过，而 Gevent 的协程机制就很有点纤程的意味。Gevent 就是一个异步 IO 事件响应的框架 + 高性能定时器阵列，并发性能相当惊人，当然也有部分缺陷，容后再述。

发现的问题

　　当然，在项目中也受过不少苦头，例如策划拍脑袋改需求的事，还有各种上线前爆发的疑难 bug 侦错，真个是步步惊心。于是私下总结了一些经验教训，希望将来的自己能记住。

　　架构上

　　　　从初期版本上看来，设计的时候还是比较注意单一职责原则的。IO 层，业务逻辑层分野明显，业务逻辑开发也颇有点插件式增量开发的味道。可惜后来自乱阵脚，不知道是策划、老板催的太紧，还是人本身的惰性使然，后来的功能开发，都是东插一块，西垒一堆，每次提交都差不多十个文件，code review 的时候很难发现重点。

　　　　如果能够重来，我会把消息队列作为业务逻辑开发的基础。在游戏操作的关键点前后都 pub 出消息，以后的插件只要监听消息就能够进行了，不需要再到处插代码。资源的申请与释放应该有一个统一的地方完成，内存泄露也容易查，功能代码上也不需要做很多冗余的错误处理。开发新功能时，尽量以插件的方式提供，资源则由框架提供。

　　　　当然，这一切都取决于项目的概念完整性。整个项目的架构设计 ，应该由一到两个人完成，其他人的好建议可以吸收，但总的概念和走向应该由这一到两个架构师把握，从全局上统筹开发风格，避免项目变成大杂烩。

　　gevent

　　　　gevent 的并发性能相当优异，而且结构简洁，对我等开发者而言实属福音。但是，游戏里遇到一种情况，例如打击计算、ai 逻辑等部分，希望越快执行越好，而数据查询类的操作，例如排行榜，则可以接受较大的延迟。Gevent 的调度器没有优先级的概念，这里可能需要自己 hack 一下，或者更进一步的分离开数据查询操作，以此提高打击判定的速度。

　　版本控制

　　　　在项目的开发过程中，越来越感到版本控制的重要性。新功能提交和 bug 的提交不要混淆，尽量做到每次只提交一个功能点，普及 code review，bug tracker 和 code commit 可以考虑联动。如果用上 git 或者 hg 做开发支持，每个新功能作为一个分支，若发现影响很大的 bug，就可以整个分支抽离，将对其他功能的影响降低，也提高了版本发布时的代码稳定性。