2022-北航敏捷软件工程-提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2022 年北航敏捷软件工程 |
| 这个作业的要求在哪里 | 个人作业-提问回顾与个人总结 |
| 我在这个课程的目标是 | 了解并体验软件工程，实现从「程序」到「软件」的进展。 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾一学期的软件工程课程，总结所学与收获。 |
阅读提问回顾
问题一：单元测试为什么必须由程序的作者来写？
单元测试必须由最熟悉代码的人（程序的作者）来写。
代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。
——《构建之法》第 2 章 2.1.2 好的单元测试标准
结对编程中的两个事件可以一定程度上解答该问题：
- 命令行参数的错误处理部分是由潘佬完成的，单元测试则是由我来编写的。这个过程某种程度上相当于一种独特的「代码复审」，我们在这个过程中对题目的描述的理解更加明确，并在这个基础上对相关 bug 进行了修复。这说明了由程序作者之外的人去进行单元测试是非常可行也是很有益处的。
- 单词去重部分的逻辑是由我来完成的，而求解单词环相关的单元测试也是由来我编写的。在两种情况中我没有对单词去重，而后续逻辑会导致结果中出现相同的单词，但我阅读题目的过程中理解出现了偏差，认为这种情况是可以出现单词重复的，所以完全忽视了相关的单元测试，幸亏 DDL 前在潘佬的提醒下我发现了这个 bug，最终将其修复。这说明了如果只由程序作者去写单元测试，因为编写者囿于自己的逻辑，会导致一些简单到离谱的 bug 根本测不出来。
由此可得，在本学期结对编程这种「需求描述复杂度远高于代码编写难度」的项目中，由非程序作者来编写单元测试是非常重要的。当然，正如我在提问时所写，并不是说程序作者就不需要编写了，对于以「代码编写难度」为主的项目，其他人很难对相关细节进行针对性测试，这时程序作者亲自编写单元测试仍是不可替代的。
问题二：使用随机数出现错误时，为何不能重现？
问：如果用随机数以增加测试的真实性，好么？
答：一般情况下不好，如果某个随机数导致程序出错，但是下一次运行又不能重复这一错误，则于事无补。我们还是要用随机数等办法「增加测试的真实性」，但不是在单元测试中。单元测试不能解决所有问题，不必期望它会发现所有的缺陷。
——《构建之法》第 2 章 2.1.2 好的单元测试标准
结对编程中，对拍测试 部分我便使用了一个稳定的随机数生成器。当这个测试点没有通过时，我可以很容易进行复现（例如再次运行），并通过一定的调试发现 bug 从而修复。
由此可得，只要使用稳定的随机数生成器，出现错误时是可以复现的。
问题三：结对编程中，两人角色为何要互换？
结对编程中驾驶员和领航员的角色要经常互换，避免长时间紧张工作而导致观察力和判断力下降。
——《构建之法》第 4 章 4.5.3 不间断地复审
本学期的结对编程，我认为题目非常失败，整个题目可以大致分为以下两个部分：
- 偏「软件工程」的要求，包括但不限于 Visual Studio 相关功能的使用、GUI 编写、动态链接、暴露接口、前后端解耦对接、令人迷惑不已的题目描述等。
- 偏「程序」的要求，具体来说，一个字符串处理 + 一个 DAG 最长路 + 一个 NP 问题。
整个过程中偏「软件工程」的要求占据了绝大部分，然而这部分很难进行结对编程，因为大部分时间都是在试错和搜索，强行结对只能变成两个人一起试错和搜索，远不如分工后各自完成的效率高。
结对编程的意义是在编写复杂代码时可以做到实时代码复审，就地解决尽可能多的 bug。因此只有当偏「程序」的要求占据主要部分，拥有一定的复杂度后，结对编程才变得有意义。换句话说，对于简单而且很快能写好的代码，为什么要两个人一起写呢？本学期结对编程的作业显然不符合这个要求。
综上所述，我认为本学期结对编程的作业可以让我们很好地在实践中了解实践工程，但却不是一个适合结对编程的项目。
最后回到问题本身，我还是持有原来的观点，那就是两人角色没有必要互换。此外我还有一个新的问题，那就是工程中需要编写「足够复杂」的程序的项目是否占据主流？这个「足够复杂」的含义是采取结对编程可以最大化经济效益。
问题四：书中的冲刺部分是否适用于我们的课程？
在冲刺期间，外部人士不能直接打扰团队成员。一切交流只能通过 Scrum 大师 (Scrum Master) 来完成。这一措施较好地平衡了「交流」和「集中注意力」 的矛盾。有任何需求的改变都留待冲刺结束后再讨论。
——《构建之法》第 6 章 6.1 敏捷的流程介绍
这个问题助教已经进行了回答 ：
对于不合理的需求，先挂起这个需求，先做本次冲刺中其他的需求。
很感谢助教的回答，我认为将助教的回答和书中内容结合，这个冲刺的流程在一个实际工程中是很合理的。
但我依旧保持原有的观点，即这样的流程并不适用于我们的课程。因为我们除了这门课还有很多其它的课，实际的环境和一个真正的「冲刺」流程区别还是比较大的，如果有大量需求都被挂起，放到最后根本就做不完了，更有效率的方式是在 Scrum Meeting 上直接更改需求，这一点在团队项目的开发中也有所体现。
问题五：工程师不等设计师的线框图怎么开始工作呢？
用户体验和用户界面设计的目的是什么？有哪些步骤呢？一些没有经验的工程师觉得，「我先把代码写好，然后有一些会画图的人来把界面改一改就好了……」，这种想法是非常幼稚和有害的。另一方面，如果认为工程师只能等着设计师的线框图才能开始工作，这也是同样幼稚的。
——《构建之法》第 12 章 12.2 用户体验设计的步骤和目标
本学期的团队项目开发中，前端使用 MVVM 架构，我负责视图模型层 (ViewModel) 的设计和编写，视图层 (View) 则交给团队内有着平面设计经验的成员来负责。这其实就是「我先把代码写好，然后有一些会画图的人来把界面改一改就好了……」的一种体现，这与提问中设想的「功能开发和美工解耦」完美契合。
问题六：真的有用户嘛？
提问中我认为想要真正拥有有意义的用户，只有两种选择：
- 为学校服务，包括：
- 为课程服务，包括航概刷题库、课程平台等。
- 为整个学校服务，包括教务系统、投诉平台等。
- 进行小型的创业。
事实上，本学期拥有真正意义用户的项目依旧走的这两条路线。因此我保持原有的观点，想获取有意义的用户量，还是只有这两个选项。
作为一门大三下的软件工程课程，是否一定要将获取用户量来作为体验软件工程的一部分，我认为这值得商榷。
知识点总结
需求
NABCD 分析，提供了五个很好的角度来分析一个产品，包括 N (Need，需求)、A (Approach，做法)、B (Benefit，好处)、C (Competitors，竞争)、D (Delivery，推广) 五个方面。对于一个计划中的产品，使用 NABCD 分析并辅以充分的数据调研，可以更有说服力地说明一个产品可以满足使用者的需求。
设计
MVVM 架构，全称为 Model-View-ViewModel，前端部分视图层 (View) 和视图模型层 (ViewModel) 高度解耦，视图层呈现具体的界面显示，而界面中的数据则来源于视图模型层；视图模型层则负责和模型层 (Model) 进行交互。借由 Vuex 状态管理，视图层和视图模型层可以在不同文件中独立编写。
依靠 MVVM 架构，前端设计时可以统一确定某个页面的全部功能，之后负责视图层的成员专注于界面的设计和美化，负责视图模型层的成员专注于相关数值的维护以及所需的 API。
实现
服务端渲染，是指由服务端（而不是客户端）完成页面的HTML 结构拼接的页面处理技术。这项技术可以有效减少首屏渲染的白屏时间，并有利于 SEO (Search Engine Optimization，搜索引擎优化)。团队项目中，我们使用 Nuxt.js 框架实现服务端渲染。
测试
单元测试，可以针对单个模块进行最基本的测试，类似于「样例」，可以有效避免一些非常愚蠢的错误，一定程度上「保证代码至少是过了样例的」。单元测试存在一定的局限性，一方面样例多为手动构造，强度难以测出深层次 bug；另一方面针对中小项目的前端适用性较差，效果远不如一次完整的场景测试。
发布
初始用户数据 非常重要，远比大范围、大强度的宣传更加重要。具体来说，作为一款求职软件，如果有很多的求职者，软件里面却没有招聘信息，那么求职者们看一眼就不会再来了。因此如何有效获取合适的初始用户数据是一件非常重要的事，也是一个值得探讨的难题。
维护
前端维护后的 实时更新，微信小程序的更新需要审核，加急审核的次数每年是有限的。而网页端很好实现实时更新，因此一种可行的方案是在微信小程序中嵌入 Webview，在扩展微信小程序功能的同时，也可以更方便地进行维护后端实时更新。
个人感想
个人阅读作业，量子波动速读《构建之法》，绞尽脑汁提出了六个问题，很庆幸能在课程结束时对六个问题做一个回顾和总结，也能在实践过程中对《构建之法》的一些概念有了更加深刻的理解。
案例分析作业，一开始本来想选 QQ 音乐和网抑云，结果发现找不到 bug，遂转战 CSDN Bug Tree。众多的 bug 让我难以想象这是一个大公司上线的产品，也我碰到了没做好测试就上线的限量版闪现 bug，可以说是为我们展示了一个「失败」的软件，时刻警醒我们脱离软件工程很难做好软件。
结对编程，虽然结对元素偏少（见问题三的回顾），但在潘佬的带领下，我们还是体验了一次极限的软件开发，最终顺利完成了所有任务，从基础的计算核心，到错误处理和单元测试，再到 CLI 和动态链接库，以及最后的 GUI 和松耦合，我们亲身实践了一次小型软件工程，对软件工程有了进一步的认识。
团队项目，一次次 Scrum Meeting，一次次燃尽图的绘制，一次次文档的撰写，从微信小程序到网页端，从采访内推学长到向老师们推销求职岛，在团队成员齐心协力的共同奋斗下，我们完成了预定的目标，成功打造了求职岛这一平台。整个过程虽然艰辛，但我不仅收获了崭新的技术和团队协作力的提升，更是在整个过程中体会到了软件工程的深层次含义和团队合作的精髓所在。
最后，感谢老师们助教的辛苦付出，为我们提供了一个自我实践的平台；感谢结对编程队友潘佬，带领我一起挑战极限、突破自我；感谢无际软工队的全部队友们，共同克服困难，齐心协力完成了整个项目的开发。
