今天是 5 月 31 日，我们的游戏的 alpha 版本的开发也快接近尾声了，回望 5 月的开发经历，我感慨颇多。我在团队中处于比较核心的位置，可以毫不谦虚地说，我的工作对整个团队工作的走向的影响是非常大的，因为我不仅是组长（负责管理），也是全栈开发人员（负责解决前后端和运维中的技术难点）。但我并不是项目经理，需求和产品设计的工作是付千山同学做的，我可能更像技术总监。
在写这篇文章时，我先打开了 git ，看了看我们仓库在 5.1 时候的状态。幸好我们团队一直是用 git 对规范地管理代码，所以今天在总结时，我能清楚地知道这一个月来我们开发了哪些东西。5.1日时，dev 分支的 commit 数是103，5.31 日时 dev 分支的 commit 数是 284，这一个月我们提交的次数比3月和4月总和还要多。5.1 时，前端在 github 还只有一个测试页面，后端对用户的处理逻辑也还没写完。5.31 时，前端已经只剩游戏界面和用户界面了，后端只剩游戏逻辑了。总的来说，这个月的开发进度还是推进得非常顺利的。
我打算从两个方面来谈一谈这个月我的心得体会。
先说技术，后端的技术难点有三个，第一个是游戏逻辑的处理，第二个是邮件的处理，第三个是 scala 的 actor 和 java 的多线程模型的结合。第一个问题是 5 月快结束时解决的。在操作系统课和程序语言课的助力下，我成功找到了它的解决方案：前后端采取问答的方式进行数据交互，前端问后端：”我上一个问题的答案是xxx，下面我应该做什么？“，后端回答前端：”上一个问题的反馈是xxx，你下面应该做xxx决策。“，这样一问一答的模式可以方便地完成交互。前端只需通过 ajax 发送请求，并注册回调函数，就可以做到在收到后端答复的时候再进行下一步操作，避免了轮询。后端只需要通过异步编程，在适当的时候返回前端的请求的结果即可完成交互。后端的异步编程涉及到多线程共享状态的访问问题，因此应该谨慎地使用 Java 语言提供的 synchronized, wait, notifyAll 等函数进行多线程编程，在避免轮询和忙等的情况下避免发生死锁；第二个问题的解决步骤有三步，第一步是注册一个可以开 smtp 的邮箱，第二步是去阿里云管理界面解封了 25 端口，第三步是修改了部分发邮件的代码。这个问题的解决过程比较平凡。第三个难点是 Scala 的 actor 模型和 Java 多线程模型的结合，这个问题是我没预料到的。一开始选择 Scala 和 Java 混合编程，以为只需要解决混合编译的问题就好了，现在发现，两个语言在处理一些事情上的思路和模型不太一样，这些东西也是需要仔细考虑的。最终我的解决方案是，Java 里的 Checkers 模块全是静态的，没有副作用，God 模块的代码需要保证线程安全，但自己并不处理线程的创建，Scala 里的 akka http 框架会为每个请求创建一个隐式的 actor ，我们没法控制这个 actor。但这个 actor 可以接收 Future，也就是说我们可以另外开线程来完成比较耗时的操作，而开线程这个过程我通过 Future 来完成。Future 需要一个执行环境，里面有关于线程的调度的配置，这个配置可以用全局的默认配置，但更好的做法是使用 ActorSystem 的 dispatch 提供的配置。关于 Scala 的 actor 模型，有时间我还需要仔细了解一下。
前端的技术难点有两个，一个是游戏框架 phaser 提供的东西都是在 canvas 里显示的，而且没有提供输入框，选择框等输入控件。我先尝试了第三方插件，但效果非常不理想，后来我找到了一个解决方案：把浏览器原生的 input 控件放在 phaser 画布上，只需要把控件的 position 属性设为 absolute 就可以做到了。前端的第二个技术难点是多个页面之间的消息通信问题和多个页面重复加载资源导致显示不流畅的问题，这个比较简单，只需要把所有控件放在同一个页面上，然后每次显示一部分，隐藏一部分。控件是通过 jQuery 提供的 show 和 hide 函数来实现的，画布上的东西是通过 phaser 提供的 state 功能实现的。
下面就要说说管理了，五月初我发现前端进展非常缓慢，于是和朱池苇同学一起加入了前端的开发。前端原先是安排给吴同学和付同学来完成，因为吴同学基础不够好，付同学又主要在做产品方面的工作，导致前端进展非常缓慢。这个事情有我的责任，我没能了解清楚大家的基础，导致人手分配不均。吴同学一个人做前端，没有人指导他，也没有人帮他解决困难。他一个人花了很多时间，做了很多无用功，留下了许多不能用的半成品代码，造成了资源的浪费，这是我作为管理者的失职。后来我和朱同学加入了前端，为前端开发铺平了路，这时吴同学生产力就提高很多了。另外一个值得一提的是欧阳同学，我一开始给欧阳同学安排的任务是后端，他写了一段时间，效果并不是特别理想，后来因为前端需要，我让他画了一些界面，结果发现他平面设计做得相当不错，就让他做了一些设计相关的工作，直到后来老师给我们请来了专门做设计的同学。然后我让他去做前端了，又让朱同学回来做后端，这其实有一点浪费，但确实是由于业务逻辑的需要，朱同学必须回来写后端。前端人手又不够，所以必须让欧阳同学去写前端。明明可以分工协作的，结果朱同学和欧阳同学都在前后端之间切换，导致开发周期变长，这也是我的责任。
另外我作为管理者，在绩效这一块也做得不是很好，没有给组员及时的反馈。做得好的地方，应该表扬，做得不好的地方，应该批评。及时的反馈有助于调动开发的积极性。不过很好的是，我们团队的整体氛围是很欢快的，大家都很积极地参与开发，并没有划水的同学，所以绩效考核这一块的短板并没有造成太大的影响。
管理中很重要的事情就是要让大家在对的位置上发挥最好的效果，这也是我今后应该努力的方向。五月有收获也有遗憾，希望今后的开发我能做得更好。