正想着团队项目中数据该如何解析，就收到了来自软工课程组的一件小黄衫，真是意外之喜。详问其来源，竟是因结对项目做的“较好”而来，顿感受之有愧。
结对项目是两人对文件系统的一个小模拟，尽管也有多人合作、需求分析、架构设计及优化、代码实现和测试、进度管理等多个组成部分，与传统的 OO 题目不甚相同，但与真实的团队软工还是相差较远的。这种题目的需求是相对明确、能够进行近乎严格的正确性测试的，而在团队项目中，我深刻地体会到真实项目的需求分析远远难于此。
团队项目不是一个问题的需求分析，而是多个问题：比如我们团队近取 Key ，在后端需要单词数据以及单词间关系的数据，这些数据有的可以直接从 mdx 等字典文件解析而得，有的需要从网络上爬取、搜集各种类型格式的文件而得，但最终都需要以统一的格式存入数据库中，其中每一部分文件的解析都需要进行需求分析和设计，以及错误设计：因为很多数据都是经过了人手，必然会存在一些错误（比如 submit 写成 sumit 等），如何尽量少地避免因为数据的错误而导致推荐的不准确、如何将获取数据中用户所感兴趣的数据提取出来，每一个任务都需要一个较为完整的流程，甚至任务之间可能是并行的。因此，为了防止处理失误，在开发时我不得不在 issue 中明确每一步的处理、完成状态（如这一个 issue），并撰写详细的需求分析和设计文档以备查看。奇怪的是，并不是课程组要求我们做 issue、要求我们写文档，而是这些问题都是我们开发过程中理所当然要做的，我们需要做，那么自然而然的就会去做。部分方法的单元测试也是，认为可能出错，那么就去做，而有一些逻辑过于显然的方法，我们也暂且没有做测试，不知这样处理是否得当，最后的结果就是单元测试的覆盖率较低。
个人博客、结对和团队开发的过程都是非常紧张而愉快，同时又收获颇丰的，非常感谢课程组能够为我们提供这么一个实践软工的机会；但同时在团队开发初期，课程组似乎下偏了功夫，导致我们团队需求分析很明确的情况下还需要受到较大的来自奇怪主观判断的压力，因此收到黄衫后也一直没有时间写这篇感言；不过总体的感觉是很棒的。希望能够在 Beta 阶段更加丰富自己的软工实践经历，更加深刻地认识和实践软工。
btw，搜索黄衫全是倚天屠龙记里的黄衫女子，不知道课程组是否有此隐喻，哈哈。黄衫上的 Learning By Doing 蛮赞的。
 |
 |