软工完结——提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2021春北航计算学院软件工程（罗杰 任健）
这个作业的要求在哪里	Here it is.
我在这个课程的目标是	1. 体验体系化、规范化的软件工程实践流程。2. 锻炼码力。
这个作业在哪个具体方面帮助我实现目标	回顾学期初提出的问题，总结课程收获

提问回顾与解答

Q1：全自动化生成单元测试

在结对作业中，我和队友都人工书写了大量单元测试，但我依然对全自动化生词单元测试的可行性进行了一定的思考。通过列举撰写单元测试时的一些心路历程，让我们来看看是否可以自动化地实现：

（前情提要：结对作业针对文件系统，大多输入输出为字符串形式）

我的心路历程	全自动化生成预期
普通情况/正常用例	可以生成，但需要指明输入格式
构造边界数据，包括根路径、超长路径等	可以生成，但需要指明输入格式
各种异常情况的覆盖	比较困难，随机生成命中异常情况较少
查看覆盖率，针对未覆盖部分专门构造用例	比较困难，程序难以直接根据代码分析可以覆盖其的样例

尤其针对本次结对作业类似的非数字型输入的单元测试，我认为自动化生成单元测试的难度更大。为了保证数据的规范性，需要提前对数据格式进行约束，而程序员的约束可能会影响自动化单元测试的效果。另外，针对对覆盖率要求很高的单元测试，自动化生成的样例也难以保证覆盖率。

但是，我认为对于部分边界情况和普通情况，机器是可以做到自动生成的，但是最终往往需要人力对机器遗漏的细节进行补充，或者对不合理用例进行筛查，最终达到：

把重复的部分尽可能消灭，让人来写最少的

Q2：改进别人的方法，是否一定不会有突破（或突破一定小于作者本人）

在本学期的团队项目进行过程中，前端在某些模块的实现参考了市面上现有的各种画布编辑平台的布局实现，我们选取了不同软件中我们认为最具亮点的部分，并进行融合，最终构成本项目的前端整体布局架构。我们曾参考：

• Processon 画布界面及主页
• Github 主页
• 知乎登录界面
• WPS 界面
• Prezi 界面

仅从成品前端的质量来看，我们认为我们的产品相比被参考的成熟软件，总能找到做的更好的细节或角度。因此，我认为借鉴别人的方法后，也能有所突破。这种突破可能源于我与原作者的认知差异或知识不重合的地方，凡事换一个人做，往往就能得到一个完全不同的结果。

Q3：在MVP方法中，如何保证雏形产品的不完备性不影响用户反馈？

在 alpha 版本结束后的用户体验反馈部分，我对该问题再次进行了思考。

由于我们团队的项目新颖度高，目前市面上暂无类似的产品，因此用户对本产品大多没有预期的目标或期望值，更大的问题反而是在理解这种新产品的使用方法和理念上。因此，alpha 阶段产品的不完备性没有对用户反馈造成很大的负面影响。

但是，我们依然遇到了不少用户反馈的问题，其中不乏对 beta 阶段待实现功能的要求，这些反馈其实是对当时用户资源的一种浪费。因此，我认为在发布文档中详述本项目待完成的内容，将在计划范围之内的功能及时向用户传达清楚，能很大程度上防止用户在此方面倾注笔墨和时间。

Q4：不同类型产品的迁移成本关键问题所在？如何减少迁移成本？

迁移成本也是我们团队的软工项目需要面临的问题。

市面上大多数的背单词软件都存在”打卡日历“功能，并且对用户的背单词进度有详尽的记忆，因此在用户背诵某部分词书到中途时，转战其他背单词软件的迁移成本极高。为了获取更广泛的用户量，需要在迁移成本方面解决以下两个问题：

• 如何减小迁移成本？

  我们通过实现用户通过搜索自定义加词的功能，让用户在选择背诵的单词列表方面具有更高的自由度，甚至可以让用户将本软件和其他背词软件结合使用。

• 如何让用户愿意支付迁移成本？

  软件本身的质量、功能的完善程度和用户的使用感受做得越好，就会有更多的用户愿意支付迁移成本来使用新软件。

Q5：专业性产品是否需要考虑非专业类人群客户

我们团队的软工项目是一款背单词软件，在如今全民学英语的社会环境下已经不属于专业性产品了。但是，相对于PC和平板使用不流利的广大用户群体来说，使用本软件仍存在一些技术壁垒。

从我们的开发过程来看，如何降低非专业人群的使用壁垒是产品推介中非常重要的部分。这其中设计用户使用逻辑的合理性、教程的完备性、提示的充分性等多个和用户使用体验直接相关的软件设计环节。对于一款从理念上上手难度本身就较大的软件来说，在使用方面更需要充分考虑非专业人士的操作简便性，争取做到“不让用户问为什么”，”少让用户做选择题“。

Q6：一个优秀的创新是否一定逃不过泡沫阶段？如何快速从泡沫中跳出？

正如在我提问时一位老师在评论中的指点：

泡沫对整个社会而言未必是坏的。

泡沫时期又称“期望膨胀期“，可能来源于公众的舆论、炒作，又或许源自于人们对其中潜在利益的狂热追求，从而诞生的许多未经斟酌、质量参差不齐的产品或理论。从前的我可能只抓住了这段时期的部分产品”质量不达标“的缺点，却没有考虑在市场处于极度活跃状态到时候，给某些技术发展带来的资源和机遇。

丰田 2JZ 发动机就是诞生在泡沫时期的产物。当时日本汽车行业疯狂膨胀，制造商在设计和零部件设计上资金充足，甚至浪费，这种无视成本的投入，才造就了 2JZ 的诞生和丰田最终的声誉。泡沫时期给相关行业带来的发展空间可以给予他们足够的机会进行创造，也一定程度上可以为新产品、新理念的诞生创造可能。

Q7：Bug Bar的确定基准

仅半个月的单次开发周期让我们的项目几乎不可能以完美的形态呈现给用户。在测试阶段，我们也形成了大家共实 的 bug bar 标准，并据此对所有的bug进行了优先级的划分，在修复所有 bug bar 之上的漏洞后即达到基本的出厂标准，在出厂后继续修复 bug bar 之下的漏洞并逐步提升 bug bar 的要求。

在我们的开发中，所有涉及安全性、功能性的bug全部都在bug bar之上，即需要保证系统的功能没有能被用户使用察觉的问题。因此bug bar下的漏洞多为前端的对齐、语言统一等ui层次的问题，the highest no 为不影响使用的适配问题。但通过后续的发布和用户反馈来看，一些不影响使用的显示问题有时也会大大影响用户的使用感。因此，若想达到更好的成果，bug bar对前端的要求还应进一步提升。

新的问题

1. 结对编程在真实生产中是否有应用，主要应用在什么开发场景中？

   仅从本学期的体验来看，结对编程单从开发速度上是小于二人分工分别开发的。那么在真是生产中，是否有开发场景常使用结对编程的方式进行开发？

2. 功能测试是否有相关方法论？

   团队项目中，我们的功能测试多采用在不同设备上尝试主要功能的方法进行。但是，始终有功能细节错误或者不会百分百复现的错误出现。有什么方法提高功能测试的效果吗？

知识点

需求

• NABCD中的 Delivery 关注产品推广到目标用户的途径和难易度，也是软件需求分析阶段需要提前考虑的重要环节。
  • 在 alpha 阶段没有将产品对广到目标用户群体，beta 阶段进行了相关改进。

设计

• 即使是根据全新理念提出的新软件，也应在部分功能设计时考虑用户普遍使用习惯，尽量贴近现有的逻辑规则。
  • 虽然”词图“背单词法是新颖的，但是针对每个单词卡片的学习、用户界面的设置和社区分享的逻辑应当贴近现有的背单词软件和分享平台，这样能降低用户的上手门槛。

实现

• 系统实现过程中需要提前指定规则。其中包括样式规则、命名规则等，以便于应对功能变动等突发情况。
  • 在实现某一功能时，为了让该功能和完整项目的衔接更自然，往往会派生出其他不在预期范围内的过渡功能。提前指定实现规则，并按照规则临时增删功能，将简化过渡过程，让不在预期之内的功能也和项目融合密切。

测试

• 回归测试需要持续跟进，包括功能测试的回归。
  • 部分前端组件之间具有依赖性，在修改后如不进行回归测试可能会误伤曾经正确的功能
  • 另外，功能测试中，人手是很重要的资源。目前，人手数≈设备量→设备多样性，对于适配的测试格外重要。

发布

• 用户反馈的收集需要采取多种途径，并且不同途径谁寄到的反馈效果不一。
  • 从项目的用户反馈页面收到的评价通常内容完整，叙述详尽，大多着重于主要功能的建议。
  • 从内测群喝用户直接交流得到的反馈较为零碎，涉及用户使用感等细节，并且可以从双方交流中进一步深化。

维护

• 充分利用自动化工具简化后期工作流程。
  • 通过在 CI/CD 实现自动部署可以简化后期的部署过程。

心得体会

个人项目

在热身作业中，我对我的学习生涯和我与计算机的羁绊进行了反思和回顾；在《构建之法》阅读作业中，我时隔多年再次完整读完一本书，让我对软件工程的学问有了初步的认知，提问的要求也让我全程边读边思考；在案例分析作业中，我通过对比多个常用笔记软件的功能、ui等，对于如何做出用户体验更好的软件有了自己的认知，也让我关注到了从前没有意识到的软件设计细节。

综合来看，个人作业带我真正走进了软件工程的世界，将我原本 take for granted 的软件工具的内在学问呈现了出来，原来软件工程远不是写个代码这么简单。

另外，这几次博客作业也锻炼了我的笔力，让我认识到了我在博客排版上的不足。

结对编程

结对作业中，我有幸和队友 lcy 共同完成。我们经历了前期收集资料的摸索、具体实现时的磕磕绊绊、测试修锅时的举步维艰。

抛开题目本身，在结对作业过程中我还是体验到了一些结对编程的新鲜感。虽然由于时间等客观原因，全程以领航员和驾驶员的身份结对编程较为困难，但我们还是在关键方法的实现上落实了一人写、一人监督、共同讨论的配合模式，确实提前规避了很多错误的产生。和队友充分的交流和计划能规避后期开发中二人很多的不一致代码习惯产生的冲突，让我们的合作更加顺畅。

从题目本身而言，我通过本次作业回味了 java ，捡起来了可能已经生疏的面向对象编程能力。

团队项目

我很感谢团队项目的机会，让我体验了将灵感落实到软件的全过程。

首先，这一过程让我深刻体会到了软件工程每一环节的重要性以及环环相扣的依赖性。果然书本上的都是抽象的，要想真正理解必须要自己落实。需求分析的重要性我们在过程中有了越来越深刻的认识，它不仅考虑是否有人需要用它，也需要考虑我们能否把它送到需要用它的人手里；设计实现时，我们对所有功能的实现度都提出了最高的要求，根据提前制定的规范对所有预期目标进行拟合……在开发中，无论是我们团队自己还是课程组，都对我们的项目提出了远高于课程作业的要求，我甚至感受不到我只是在上一门必修课，我感受到的是我在一个企业中想尽办法用自己的知识和技能创造出真实的生产价值。

另外，我要感谢美滋滋甜兮兮团队的所有成员，他们是我整个课程收获的最宝贵的财富。持续线下开发，无人摸鱼，每个人都在团队中发挥着自己的长处，往往都能交出超出期待的成果，大家的陪伴和集体开发时的欢笑总能疏解我的劳累压力和怨言，要用一个字概括团队项目的过程，那就是“爽”呀。

一门课程，囊括了社会中的众多黑白人情世故，纵然栉风沐雨，愿我们不忘初心q(≧▽≦q)