2016 软工个人总结 与 CamusAPI - 纯纯的 Blog

2016 软工个人总结 与 CamusAPI

这学期（又）上了一遍软工3，一开始准备做个微信端的校园服务公众号，后来感觉不是很喜欢微信开发，需要纠结很多微信 API 和权限的问题，所以更换了纯 API 的项目。

CamusAPI 这个项目的初衷是希望建立一个清华内部的校园开放 API 平台，供校园应用的开发者使用，不需要处理复杂的爬虫逻辑和页面逻辑，将学校的系统封装成一层清晰完整的 RESTful API 系统。

由于本来就有比较丰富的开发经验，知道架构对整个项目的重要性，所以一开始的项目架构是我独立完成的，将项目根据功能划分成了好几个模块，尽可能地减少模块间的耦合。此外，考虑到去年开发紫荆之声时代码风格的丑陋和整个团队开发风格的不一致，我又提前配置了 ESLint 和 travis-ci，确保整个团队的代码风格完全统一且严谨，对诸如每个函数的行数，每个文件的行数，最大缩进层数也做出了严格的限制，不通过 ESLint 的 commit 不会被合并到主分支，虽然这会增加一些开发时的成本，但是比起团队成员互相维护代码，以及可能的重构时带来的便利，这些成本是微不足道的，也很感谢组员的配合。

之前的开发中经常遇到本地开发完到最后不会部署的情况，所以这次在架构完一开始就配置好了 Docker，并且每天从 master 分支部署一次，这样对联合调试也帮助很大。

测试是软件工程中非常重要的一环，比较遗憾的是我们组由于开发周期非常紧以及测试相对来说困难，没能采用 TDD 的开发模式，不过在最后的一周我们补全了必要的测试，我们核心模块的测试覆盖率超过 95%。不过这次被坑的是性能测试，由于对 NoSQL 数据库的原理不够了解，一开始设计数据库的时候踩了坑，使用了不合适的组织方式，也因为没有提前性能测试，直到接近 ddl 的时候才发现性能很差，经过重重排查后发现是数据库的锅，连夜重构，索性前期架构模块划分合理，数据库操作被包在一个模块里，所以重构没有遇到很大的困难，吸取的教训是每添加一个功能都该进行一次性能测试，这样既能实时 profile，也能及时发现不合理的操作避免无谓的重构。

作为 API 小组，我们的文档非常重要，不过我们组都不是很擅长写文档，这里感谢马子俊同学承包了几乎所有的文档工作，写出了完整的接口文档供其他组的同学使用，并受到了好评。

不过担任 API 小组也让人体会到了甲方的坑爹之处，毕竟别的组的项目都是自己提需求，自己伪装成用户，可以什么好做做什么。起初我组只打算给一到两组提供 API，甚至没有的话完全可以自己搭建客户端来展示，后来在老师的要求下为其他所有组提供相关的 API，不得不说这并不是个愉快的体验，我组面临二十来个甲方提需求不堪重负，甚至相当一部分需求是受限于学校系统无法完成的，虽然让他们自己做他们也完不成，但是要求我们提供的时候丝毫没有觉悟。此外我们原来希望联合的小组开发进度不要太快，这样我们可以比较优雅地组织我们的代码，但部分强力的组加入后我们不得不赶工。出于尽可能让他们能够稳定开发的目的，我组不得不先以功能为第一目的，在安全性、性能等原本很重要的地方做一些让步以适应他们的开发。而且人多口杂需求多，在某些新加入的组的要求下被迫做出一些对已经稳定的 API 修改接口的行为，从某种程度上来说我们拉低了他们的开发进度，他们拉低了我们的代码质量。

这个项目从功能上来讲并不是我开发过的最复杂的应用，实现的功能也比较基本，但是从组织模式上来说是最工程化的，也在合作中收获了很多，感谢软工课给我的机会。最后，对课程的建议主要是前期文档实在有点多，很多实现细节不可能在开发前就确定，文档也随着每个迭代更新或许更合理。