游戏开发观念又转变了-需要学习更多

来西山居上班有一段时间了。像我这种从小公司过来的，除了食堂的饭菜比较好吃外，也没有发现大公司有什么特别的地方。9.25我们就开始放假了，很多功能单的截至日期都是9.25。过去的这一周我都是在赶进度。因为接手的系统差不多要重新做吧，时间还蛮赶。不过今天发现功能肯定有一个单完不成了。既然完不成，也没有办法。下面进入正题。
这周我在调试好友系统。这个系统是我接手过来的，当初接手时说服务端已经完成了，接入客户端的新 UI 即可。碰巧我开始做这个功能时，策划那边也在催。我大概看了一下服务端代码，觉得加班加点差不多，我当初是周五接到单，心想这周六和周日都加班吧，下周三之前应该可以搞完，就和策划说下周三搞定，接着搞下一个内容。接下来就是苦逼的加班了。到了周一时，策划临时下了个单过来说很急要搞，只有先放下手头的了。搞完之后，第二天也就是周二，老大说要给一个服务端的设计方案。我心想代码都差不多了，直接来对就好了，对完之后发现一些问题，要改，既然是问题，那我就改了。第二天又开始急着对，我的解决方案，我心想代码都快写完了，一会就可以对。老大这时走到我的卡坐，问我为什么非要代码写完。我当时说的是“写完代码才可以确定最终的结果”。后来我回想了一下，我其实想表达的意思是这种玩法内的游戏，其实没有必要花时间还要设计什么的吧，大体上把数据的存储想好之后，就开始写代码了，毕竟进度是第一位。如果真的有什么问题，我觉得也很快可以应急过来，最多半天时间搞定。毕竟只是 UI 玩法的东西。因为之前在广州的页游公司，竞争真的很激烈，节奏很快，所以功能下来都是尽快完成最好，有问题也火速解决，这样子。所以和西山居这边的工作方式有些不同。而且之前是需要代码审核的，现在在这个项目组不用代码审核，就是说前期把想好完成代码就可以了，而我们之前就是快速完成后，其他组员会审核代码，所以虽然速度快，但是一般出问题真不会太多。还有一点就是之前说的设计设计，我一直觉得没有什么内容可写，都是玩法之类的逻辑，写代码就好。现在我知道了，先画好流程图，然后贴上关键的数据结构的设计就可以了。现在知道设计到底要表达哪些东西，我下次也好完成这部分工作了。
另一点就是后端开发。我之前的公司一个服导量时，大概就几万人吧。量比较少，后端的逻辑即使效率不好，也不会有太大问题。只要不出bug就好。所以我那时的观点就是逻辑简单清晰，效率低一点没有关系。现在做手游更觉得不用太过关注执行效率方面的东西吧。所以接手了邮件系统，发现一次查询邮件操作距离有三次查询数据库，我当时和之前的开发者确认了后，后来就觉得没有也没有啥问题。但是压测就出了问题， 邮件效率很低。后来就和同事讨论了邮件系统的改造。听另外一个同事说他们之前的一个项目，开服那几天被卡在邮件系统那里，我意识到现在还是要注重一下效率，也要更了解 mysql 的一些东西了。
总体来说：
1) 离线玩家的数据尽量少载入到内存，要考虑到中期时注册玩家很多但很多是没有用，这时全服数据载入到内存就很不好了。
2) mysql 还是要注意一下效率的。比如一个表玩家一条记录存一行。加入有 10w 个玩家，每个玩家 5 条记录，就有 50w 行。如果索引又是字符串的话会比较低效。所以尽量一个玩家只存一行数据，多条记录用类似于 protobuf 之类的东西序列化成二进制后再保存到一列中。总之要注意 mysql 表中的记录是否一直膨胀，只增不减。
3) mysql 中与需要玩家登陆时有关的操作还是要认真考虑是否有低效的可能。
4) 序列化确实是个很棒的东西，Json，Base64 编码项目中都有用到。
5) 大公司的压力测试是一个标准流程，提供数据来表明项目中哪些功能效率不高，这一点还是很赞的。