[北航软工]提问回顾与个人总结

软工个人总结

课程开始时的提问博客

传送门

• 单元测试必须由最熟悉代码的人（程序的作者）来写
  这一点有比较深的感触，在整个迭代过程中我负责的是后端的架构设计和代码实现，词典部分和auto_train模块的代码基本都是我来负责的，而我们组内有一名同学专门负责单元测试，但是在实际开发过程中，他完成的单元测试整体覆盖率很高，看起来我完成的代码没有任何问题，但在和主模块merge调试过程中仍然存在一些小bug，分析后得出原因是单元测试虽然达到了很高的代码覆盖率，但由于测试人员对于代码的设计初衷熟悉程度不够，致使一些复杂的分支和边界情况并没有涉及到，而作为一手开发人员的我却是十分了解的。所以综上所述，我认为基础的单元测试确实应该由一线开发人员在完成代码之后即刻来写，在此基础之上，测试人员应该在此基础上添加更全面的全局测试，压力测试等等。

• 规格说明书
  规格说明书的地位偏向于一种全局的需求具体化，功能阐述，架构设计，主要面向整个开发团队，而注释则是对某个具体组件的详细说明，主要面向具体的开发人员和测试人员，它们的内容侧重，适用对象侧重点都是有不同的。

• 要成为领域的专家，才能创新

  这个问题在本学期软件工程的学习过程中感觉没有涉及，目前我还是保留开学时的观点，即在目前的环境下，仅仅成为领域的专家，似乎并不太足够了。在各行各业都高度专业化的今天，各个行业领域之间的壁垒也越来越重，很多领域的专家往往会不知不觉地局限于自己的领域，所以说，领域专家只是一个创新的必要条件。那么在现在的环境下，交叉学科似乎正在成为新兴的创新爆发点，借鉴其他学科的思路的观点，结合本领域的知识，将会产生更多的可能。

软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” - 在实践中学习知识点。

新的问题

• 如何平衡敏捷开发和代码的架构设计和可扩展性设计。
• 团队分工任务时如何控制任务的精细度，过于粗放会导致容易出现完成质量差，时间拖延的问题，过于精细又无法保持足够高的效率，还会出现零碎化问题。

请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点就可以。

• 需求：需求分析和设计并不只是项目初期要做的事，而是贯穿整个项目开发周期的。
• 设计：设计阶段需要综合考虑各种因素，功能的实现难度，可靠性，新功能的可扩展性，不同环境下的鲁棒性，以及一个好的项目必须在功能角度从用户出发，而不是从技术人员本身出发。
• 实现：实现中代码的可读性要非常注意，给测试人员和之后的自己更多可读性上的友善体验。同时需要预留一定的空间给可能的新需求。
• 测试： 除了功能测试之外，还有很多其他的测试角度，也非常重要。比如安全测试，稳定性测试等等。
• 发布： 为了准时完成发布目标，需要预留出足够的发布前准备时间和风险时间，同时在开发进行过程中需要定期对项目风险进行评估，根据评估结果对计划作出一定的调整。
• 维护： 在代码实现阶段就需要考虑到维护的成本和便捷性，这样才不会堆砌大量的工作给维护人员。

结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得

• 文档和代码开发的平衡。是否课程设计过于注重博客文档。
• 对于博客文档的反馈较为匮乏，且如果有一个文档的迭代过程，而不仅仅是单次作业，可能效果会更好。
• 转会机制本身很有意义，初衷也是模拟实际开发中的人员变动，但是具体的实际规则感觉仍需改进，现在的规则太过生硬，是否也可以增加短期租借其他组人员这样的选项。
• 结对编程的模式很有意义，是否可以设计一次简单的结对一次复杂的结对，或者是3人开发，更加循序渐进