标签：常用 测试 控制 工程 部分 场景 决定 docker 镜像 技术选型
这学期软工小组的开发就快结束了，回想整个开发过程，感慨颇多。
首先是刚开学时的组队和选题，我们各自提了好多项目，有的太简单，有的没有价值，有的又太不切实际，最终我们选定付千山同学在高中设计的游戏作为题目，因为这既新颖又有前期调研，而且也比较有趣。
但其实，我之前从来没有游戏开发的经验，组员们也只了解一两门语言，几乎没有大型项目开发经验。所以，这次项目从技术选型到开发都是一边摸索一边做。现在回过头去看，有得有失。首先，Travis CI 的学习和使用是非常正确的决定，因为后端运行环境比较苛刻，不方便在组员自己的电脑上搭建。因此，我们需要快速部署更新的代码，以方便测试和调试。如果按照我以前的方法手动更新，那么效率将大大降低。这个问题还有一个解决方案，即配置一个 docker 镜像，让大家都能迅速搭建服务器。这个方案也很不错，下次可以实践一下；然而，技术选型就有些差强人意了。先说后端，后端的技术是 Scala + Java，效果并不如刚开始以为的那么好，Scala 和 Java 的交互体验并不是那么友好，一是 Scala 的库 Java 用起来很困难，二是 Scala 的常用写法在 Java 没法写，三是 Scala 和 Java 的并行控制也不尽相同，尤其是在 Scala 中使用 Actor 时。不过庆幸的是，Java 部分的代码大部分是无状态的，这方便了单元测试，也方便了并发控制。再说前端，前端使用 Phaser 和 JavaScript，Phaser 有一些坑，比如输入框和场景控制，而且 Phaser 框架整体较重，调试体验并不好。JavaScript 是一门有诸多缺陷的脚本语言，作用域问题曾给我们带来了痛苦的 debug 经历。如果重新选择技术栈，我可能前后端都选择 TypeScript，或者前端 TS，后端纯 Scala。在这次开发过程中，我也犯了好几次错误，一是场景变换问题，之前我们使用的是网页跳转，这是很不好的，会导致资源重复加载，后来在了解到 Phaser 里有场景变换后，我才花大力气把它们重构了；二是前后端在游戏中的交互，应该使用 Socket 直接交互的，我这次使用了 http，显得有些笨重，但还好前后端交互流量不大。
在项目管理上，我的经验是，在项目初期分工不必太明确，因为项目架构还没完全建立起来，模块的边界还不清晰，所以大家可以参与整个项目的代码 review，或者至少对项目各个部分是做什么的有一些了解。以及，这个阶段，我不认为应该投入很多人力，应该让经验丰富的工程师先完成项目架构的搭建，然后再进入下一步的开发。任务墙和 issue 是很好的东西，可以让我们方便地记录、讨论和拟定开发计划。另外，脏的代码应该及时重构，或者明确标注，以限制其使用范围，不然到了后期改起来会非常麻烦。
总之，这是一次非常宝贵的开发经验。在这次项目开发中，我不仅学到了规范的软件工程管理流程，也提高了自己的业务水平和与人沟通合作的能力。
标签：常用 测试 控制 工程 部分 场景 决定 docker 镜像 技术选型
原文地址：https://www.cnblogs.com/nicekingwei/p/9410876.html
