THU琴房预约项目个人总结

THU琴房预约项目终于告一段落了~~~~

以下是在软工三课程项目——《THU琴房预约》的个人体会总结，结构如下：

• 个人分工
• 编程总结
• 团队合作
• 对软件工程的思考
• 个人总结
• 课程建议

1. 个人分工

• 小组组员的任务分工
• 调研相关同类小程序
• 前端测试
• 负责小程序端逻辑实现
• 负责管理端（Vue）架构实现（整体架构，路由等）以及部分页面（路由）实现
• 前端Travis部署
• 代码分支管理及Wiki管理

2. 编程总结

（别问，问就是全栈开发）

• 首先一个好的设计方案胜过一切，如果开始的设计不好，之后实现具体的功能只会越来越窄，直到选择重构。

• 然后是尽量走出舒适区，我们小组鼓励大家多踩坑，多了解其他技术，以及不能仅仅局限于自己需要实现的方向。如果业界有成熟的解决方案，一定比自己民科解法好；如果两个人都了解数据库，两个人讨论得出的结果一定比一个人好，如果两个人都了解koa，遇到问题的时候聊一聊说不定省了几个小时查资料。

• 多用管理工具，Git必不可少，项目开发部署工具比如Travis也很重要，单元测试更是如此，核心功能必须多次测试，数据库的锁也必须饱经考验（俗称必加锁+测锁）。

• 前端开发速率基本低于后端开发速率，尤其是多前端时，后端的逻辑基本不需要变，但是前端却需要重新写很多东西，例如我们小程序端和Web管理端很多功能类似，前端需要些很多，但是后端基本重用函数就行。

3. 团队合作

在一个项目的开发过程中，团队合作真的很重要，整个项目从需求分析，数据库设计，再到微信小程序和后端开发，最后到管理端的Web端开发，除了代码量大，各种方面还需要仔细地考虑，一个人基本是不可能完成整个项目的。

因此，我觉得在团队里面分工和互补十分重要。

• 分工对于一个团队的开发效率影响非常大，如果分工不合理的话，不光影响进度，更会让整个团队混乱，大家都不知道该干什么，容易出现自己做的事情和别人冲突了或者两边实现不同导致重构，由于在之前的微信抢票过程中，我们小组有一段时间出现了一些分工不太合理，比如两个人实现同一块功能，好在我们及时开了一次会，经过大家的商讨，最终也统一了意见。因此在琴房开始的时候，我们就非常明确每个人在代码实现这一块的大方向分工（前端逻辑，前端UI，后端逻辑，数据库管理），之后我们只需要负责每个人规定（写在git的interface.md等文件上）好各自向外的接口，之后整个团队的开发效率就比开发微信抢票时的效率高多了。而且，分工好后对于代码管理也很方便，容易定位到bug的出现原因。

• 此外，互补也非常重要。实际上我个人觉得互补是分工的基础。因此，在开发过程中的每次分工，我觉得应该考虑每个人擅长的方向和不擅长的方向，尽可能让大家都在自己熟悉或者做得更好的方向开发。比如，在需求阶段，我们分成两批进行需求调研，一批进行用户需求的调研，一批进行相关类似产品的调研，沟通能力强的成员进行用户需求调研，最终用户需求调研小组与琴房管理员和部分用户进行了多次沟通，我们小组的需求方向瞬间就明确了许多。再比如，对于审美方面，我们小组的女生就比其余三个男生好许多，因此让她负责UI设计和实现这一块也是非常合理的，最终小程序的界面看起来还是非常不错的（我个人觉得简直超过了预期了）。但是做到互补地分工需要了解组员且经常和大家沟通，好在我们小组经常集体开发， 因此我们大家都较为了解各自擅长和熟悉的部分的。

最后，我印象非常深的有一次会议，我们小组在需求调研完毕后开了一次时长超过3个小时的会议，我们小组讨论了整个项目的基本功能和扩展功能，整个系统的设计方案，以及迭代周期和分工。期间我们根据调研得到的结果在白板上设计整个系统架构，大家一起想方法，最终定下了基本的系统设计方案，顿时感觉目标清晰了许多。之后的开发过程虽然有些改动，但是基本都是按照这次会议定下的路线走的（仅有1-2次大改，原因是发现不合理的设计和不够兼容扩展的功能）。

4. 对软件工程的思考

• 工程开发流程非常重要，如果不是从需求分析，原型设计，迭代开发，测试，优化等步骤来，而是想写普通的大作业一样，有了题目埋头就开始干，最后无法实现一个较为成熟，功能完善且设计合理的项目的。

• 敏捷开发很重要，但是最初阶段的设计也非常重要，绝对不能把希望寄托在迭代期间大改需求，大改系统设计。如果不是最初阶段团队对于问题的深入了解分析，是很难设计出好的系统原型的，之后的开发更不会很顺利了。个人现在觉得瀑布模型开发的思路也值得借鉴。实际上，我觉得我们团队在第一轮迭代开发初期类似于以瀑布模型开发，首先先完整全面地调查需求，然后设计，然后开始实现（如果这样结束了项目就成了瀑布模型典例了），等我们实现了基本的功能后就开始敏捷开发。因为我们最开始的设计思路基于比较完全的需求调研，最后在敏捷开发过程中获益良多，即使期间有新的需求（例如长期预约，校内接口，艺术团等），我们都可以非常顺利地将这些功能兼容到现有的系统中，如果我们一开始只是追求快速开始，快速搞出一个产品，而没有经过非常具体细致地调研分析，然后直接不断在这个基础上迭代，把希望寄托在不断的迭代周期上，之后的开发可能没有现在这样顺利。

• 代码管理。一个工程必须有对应的代码管理工具，不必细说。

5. 个人总结

• 团队开发必不可少
• 队友都非常给力呀
• 分工合理是整个团队运转起来的必要条件
• 开发时尽量考虑兼容性和性能，否则之后改难受。
• 作为一个组长，有时还是挺有压力的，主要是因为当大家都不知道怎么选择的时候，基本上是由组长做出决断的。比如我们使用koa拒绝了Django，比如我们放弃账号登陆系统，选择用手机号，再比如时间粒度选择10分钟而不是1小时，用数字串存储可用时间，web前端进行二次开发开源框架等。一些无关痛痒的决定还好，还有机会改回来，但是影响大的决定一经做出就很难回头了。如果出现大问题，整个团队的心态和氛围都会受到很大的影响的。但是最终的成就感非常大，感觉自己收获也非常大，当然也不仅仅是技术层面上的。

6. 课程建议

• 针对性较强的内容可以适量少一些。比如好几次课程都是和小程序开发相关，这对那些不是小程序开发的组来讲也不太好。而且，像Vue，react等web前端框架讲解就相对少一些，我觉得这些更加通用，可以适当增加一些内容。

• 希望有学长在开学初就来介绍介绍开发初期应该准备什么，有哪些坑，团队应该怎么样运行。

• 数据库课程似乎有些晚，如果可以的话，可以在系统设计原型阶段之前讲讲数据库可能更好。

• 微信抢票小组开发非常好，希望可以进一步扩展这种小组开发作业。