2021年软工 提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 熟悉软件工程的基本方法并尝试加以实践 |
| 这个作业在哪个具体方面帮助我实现目标 | 对学期初的疑问进行解答，并总结本学期软工的收获 |
一、提问回顾与新的问题
学期初的提问链接：2021年软工 个人阅读作业二
Q1：单元测试的构造与编写者问题
重开发而轻文档的敏捷开发如何保证单元测试样例构造的合理性？开发人员负责自己模块单元测试的编写会不会造成需求上的理解性问题？
在结对项目构造单元测试和团队项目完成后端接口的单元测试过程中我对这一问题有了更加深入的理解。结对项目中我和另一位同学交叉构造单元测试样例，即接口和单元测试不由同一人编写；而在团队项目中，我一人负责与数据库相关的各接口的编写和单元测试的构造，即接口和单元测试是由同一人编写。通过实践我发现，这两种方式都能达到较好的效果，即无论开发人员是否负责自己模块的单元测试编写都不会造成需求上的理解问题。回顾结对项目和团队项目过程，我发现我编写代码时往往是从逻辑的角度对需求进行拆分，安排具体的 if 块等；而在编写单元测试时我往往无脑对着需求构造样例，二者是完全不同的思考方式和行为习惯，我认为，此即单元测试的优势所在，也是在实际开发过程中不需要开发人员交叉单元测试的原因所在。
Q2：错误处理路径的单元测试覆盖问题
在实际的工程中对于错误处理路径的单元测试究竟应该提出什么样的要求呢？
在团队项目后端的开发过程中，Alpha阶段初期是在每个接口中检查请求方法类型并抛405，但在Beta阶段中由于接口数量骤增而使用了包裹器统一检查请求方法类型，则原有接口中的检查代码已经成为死代码却没有被及时删掉。在查看单元测试覆盖率报告的时候，我才发现这一问题并及时删去了上述死代码，避免了其逻辑上的混乱与体量上的臃肿。我认为这一情景体现了对错误处理路径单元测试严格要求的益处，即应当尽量保证单元测试覆盖所有代码路径，包括错误处理路径，而如果模块中的某个错误处理路径很难到达，那也许要想想是否可以把这个错误处理拿掉。
Q3：结对编程的效率问题
作者认为这样的结对编程方式大有裨益，可以时时刻刻处于复审的环境之中，提高代码质量和开发效率，然而事实真的如此吗？
对于这个问题，在结对项目的 第三阶段总结 中已经对结对编程的需求分析、架构设计、质量管理、结对方式等多方面进行了详细的分析与体会，并提出了数个关于结对编程的小建议，在此不再赘述。总体而言，结对编程的效果远好于我在本学期初的预期。
Q4：敏捷开发中的时间预估与备案问题
作者认为预估任务距完成所需的时间是一个重要的数据，需要进行预估，还提出了用燃尽图对任务进行跟踪的方式，这样的方式从理论上来说固然好，但我对其在实际开发过程中落地的效果如何表示疑问。
在团队项目的计划过程中，我们尝试给每个任务都确定一个预估时间，并使用燃尽图进行跟踪，然而在开发过程中，我们发现任务实际完成所需的时间远大于我们的预估，在此基础上的燃尽图难以反映项目的实际进展，对我们造成了一定的困扰。事后反思，其一大原因即是团队成员之间对彼此的技术力不太熟悉，难以准确预估特定成员完成特定任务需要的时间。但是在Beta阶段中随着团队成员的逐渐熟悉，这样的情况已经有所改观，因此可以预见的是，较为稳定的开发团队能够做到较为合适的时间预估，从而使得所述的一系列进度管理方式能够落到实处。
Q5：技术创新的关键性例证问题
作者认为，“铱星计划”想法有很多不靠谱的地方，虽然技术上有巨大创新但用户量太少，最终导致了其不到一年时间就申请破产保护，成为了一项租赁业务。然而，这真的代表着技术创新的关键性有待考证吗？
在软工的实践过程中我并没有涉及到技术创新关键性有关的问题，也没有通过其它途径有更深入的了解，因此目前仍认为这个例证是不合适的。但从另一个角度思考，全书都在极力强调用户的重要性，课程组在团队项目的全过程中也极力强调用户方面的数据，那么把这个例证仅作为对于用户重要性的强调也未尝不可。
在团队项目的实现过程中，我又产生了如下的新疑问：
- 如何确定什么时候结束计划阶段进入开发阶段？或者说，什么样的计划才是足够好的？
- 在Alpha和Beta阶段的实际开发中，我们都先是经历了数天的计划阶段再进入两周的冲刺开发阶段，可是就实际情况而言，计划结束时添加的Issue往往粒度过大，远不能满足真实需要。举例而言，计划初期我们就决定需要一个静态的项目展示页，并将这一任务分解成为“寻找模板”和“往里面填字”两个小任务，至此看起来似乎很难再进行分解了，因为更具体的内容得找到模板才知道。而若在计划阶段就找好模板，将每一部分的填字划分成多个小任务，这样的做法却听起来似乎更接近于瀑布模型，这造成了对我的迷惑。更为严重的是，这一问题也会反映在燃尽图上，当真正找到了模板，细化了任务并发成Issue，开发人员会惊人地发现：“怎么我写了一天，Issue还变多了？”从而造成难以把握项目真实进展的困境。
二、知识点提取与构建
- 需求阶段
- NABCD是一个有效的方法
- 在面对纷繁复杂的需求和团队成员的各类奇思妙想时，使用NABCD对其进行解构和组合是一个可行的方案，其包含了用户、自身、竞品三个方向上的内容，形成“三面包夹芝士”，通过这样的分析，我们可以使用简明的语言描述自己项目的特点，从而对软件工程的后续各个阶段做出方向上的指导。
- 设计阶段
- 使用典型用户和典型场景进行功能设计
- 在需求分析的过程中已经抽象出了我们真正关心的属性与其之间的关系，在设计阶段我们需要弄清楚软件应当如何解决这些需求，以及现实世界的实体和属性在软件系统中是怎么表现和交换信息的。在此过程中，使用典型用户与典型场景可以帮助团队从用户角度快速进行功能的设计，高效而实用。
- 实现阶段
- 推动信息共享与沟通
- 在开发过程中，保持信息共享和保障高频沟通是很重要的。“敏捷”的灵魂即为对随时出现的变化进行快速反应，这一特点需要建立在随时沟通之上。当然，随时沟通不是时时沟通，仍然需要留出必要的不受打扰时间进行开发工作。
- 测试阶段
- 场景测试一定要做
- 作为开发人员进行软件开发的过程中，往往是按照模块进行开发和测试，而用户在使用过程中并不是独立使用各个模块，而是将软件作为一个整体来使用。所谓“不识庐山真面目，只缘身在此山中”，跳出开发人员的角色，站在用户角度上对软件进行使用测试，在我看来尤为重要，其不仅可以发现模块间集成上出现的问题，还可以发现各流程中难以使用的部分。
- 发布阶段
- 招数：砍掉功能
- 有一个模块看起来不能实现预期的设计需求，时间快到了，怎么办？砍！从团队开发的历史经验来看，如果类似的功能需要N个单位时间才能最终完成，那么我们没有理由相信新功能会花少于N个单位时间，有时候砍掉功能是更明智的选择。
- 维护阶段
- 使用5WHY进行反思
- 5WHY指的是在问“为什么”的时候，要多问几次，层层推进，找到问题的根源。其关键在于，从现象和结果入手，不管面子问题，不管小团队的边界，沿着因果关系链条，打破砂锅问到底，直至找出原有问题的根本原因。如果针对一个问题能从各个方面深入探究，我们很可能得到一颗树状图，根部就是问题，各个枝干是分类，各个叶节点就是具体的原因，在此基础上便可以列出各类因素中主要和次要的原因，并可以讨论改进的方法。
三、课程理解与体会
本学期的敏捷软工课程大体上按个人博客、结对编程、团队项目三步走，在不考虑本课程所花费时间的情况下，这样的安排是较为合理的，能够让我循序渐进地加深对敏捷软工的理解。
在个人作业中，我通过对一些博客资料和《构建之法》的阅读，初步了解了敏捷软工的机制与亮点，在此基础上对现有软件案例进行分析，对软件工程一词有了更加深刻的理解与体会。案例分析博客也是我迄今为止篇幅最长、投入精力与时间最大的一篇博客，其中从调研、评测、分析、规划等多个角度对洛谷和LeetCode进行了深入剖析，对之后的团队项目中作为PM的我具有一定的指导意义。
在结对编程中，最大的收获即为了解并逐渐熟悉了CI的操作，虽然团队项目中我没有参与CI的搭建，但确实已经理解了CI的妙处。除此之外，结对项目更大程度上磨练了我的心态，让我面对折磨的需求时依然能够拥有良好的心态以面对，其他关于结对编程的感想与建议已经在 结对项目第三阶段总结 中较为详尽，在此不再赘述。
团队项目是本课程的重头戏。在我们的团队项目 观隅——集成式数据集可视化平台 的开发过程中，我作为PM和后端开发，与全体团队成员一起奋斗并实现了这一符合我们预期的项目。作为PM，我制定了各类接口，不断协调进度，并惊叹于实际软件开发过程中非编程资源的要求之高。作为后端开发人员，我实现了一众接口并构造了基本全覆盖的单元测试样例，在不断修Bug的过程中也有所成长。在这“做中学”的过程中，我不仅将从书中看到的敏捷软工理论应用于实际开发，解决了诸多困惑，还在与队友齐心协力合作开发的同时锻炼了沟通与协调能力，也在大量博客的书写过程中锻炼了写作能力，可谓获益匪浅。
最后，感谢谜语人队全体成员的辛勤付出。
四、一点脑洞
在我看来，课程组在团队项目的全过程中极力模拟真实企业中的软件开发场景，又是调研用户，又是转会，又是每日例会。但我认为，这样的模拟要在我们每日能投入给软件工程的时间比较富余时才有意义，不然就是“秦兵又至”的折磨。《构建之法》中多次提到：“在理论上，理论和实践是一回事，但在实践上，理论和实践是两回事。”敏捷软工这一课程设置的各阶段从学到东西的角度上来说固然好，但我认为其从某种意义上来说忽视了实践上的困难，即忽视了本科学生和真实企业开发人员之间的不一致性，忽视了学生上一门课和企业开发一个软件这两个场景之间的不一致性。
若是作为企业中的开发人员，抛开有薪酬带来的驱动力不谈，至少能够做到每天大于8小时的时间投入；然而作为本科学生而言，迫于其他课程的压力，在一些时间段内很可能每天没有一分钟是能投入给软工的，为了补偿这一时间段内的零投入，往往又需要数天的每天数十个小时的投入，两周的开发时间往往被自己压缩到不足十天，燃尽图前松后紧，这样的进度显然是不健康的。除了从自己身上找原因之外，我认为也可以从外部寻求解决方式。
一言以蔽之，以上的矛盾即为时间上的矛盾，那么有没有一个时间段能让我们有可能在全过程全身心投入软工开发，也能让课程模拟真实开发环境效果更好呢？思前想后，我的答案是暑期，即如果将敏捷软工课程的团队项目放到暑期来做，就像软件学院的小学期那样的形式，是否会取得更加的效果呢？
