软件工程-提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021年春季计算机学院软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 提升工程能力和团队意识，熟悉软件开发的流程 |
| 这个作业在哪个具体方面帮助我实现目标 | 总结和回顾这一学期的软件工程学习历程进行 |
链接到以前提问题的博客
尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。
问题1
我在《构建之法》第二版中2.1.2节看了这样一段文字
单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。
这部分可能与我曾经的一些经验不同，我认为由别人来进行单元测试，也可以达到类似于黑箱测试的效果，比如之前一些课程的测试数据由课程组提供，也能够将输入数据的各种范围尽量覆盖，并且由他人进行测试也可以避免程序员思考的情况或边界条件不周全而导致的错误。
现在我认为编写单元测试的最佳人选确实是代码的作者本人。
单元测试是来测试软件的基本功能是否正确，代码的编写者是对自己编写的代码各部分功能最了解的人。比如在这学期的结对作业中，各个函数中的分支，循环逻辑都是由两个成员协商公共完成的，只有他们两个人对代码的各个部分功能是最熟悉的，熟悉代码中可能出现问题的edge case或者如何构造各个覆盖分支的测试用例。在团队项目中原理也类似。并且代码的作者能够在出现bug后快速定位问题所在位置。
综上所述我认为还是由代码作者编写单元测试更好。
问题2
《构建之法》第二版4.3.2节中提到为了实现函数有单一出口可以使用goto语句。曾经的一些课程中老师曾经明确说过不要使用Goto语句，Goto语句容易造成程序流程的混乱。我觉得对于上述代码可以考虑设置一个变量来存储要返回的值，在不同分支中对这个变量赋予不同的值，也可以让函数有单一出口，对于某些异常情况，可以考虑使用异常处理机制。
这个问题主要涉及代码风格的一些细节，可能在一些特殊的情况下可以使用goto跳转语句。
问题3
《构建之法》第二版4.4.2节中关于代码复审的步骤中提到
> 程序员必须测试过代码。什么叫测试过？最好的方法是在调试器中单步执行。
>
> **问：**有些错误处理的分支我不能执行到怎么办？
>
> **答：**如果作者都不能让程序执行到那些分支，那谁能保证那些错误处理的正确性呢？
既要在代码复审前一步一步调试执行代码中的每一个分支，又要进行代码复审，这样的审查方式会不会由于审查过于仔细导致开发效率的降低？怎样做到既兼顾在审查中降低bug数量，又保证开发效率呢？
经过了结对作业和团队作业的洗礼。我认为很多保证代码的质量和正确性的措施看似会拖延时间，实则能节省很多以后代码中的修改错误的时间，此外仔细测试后的代码也不容易给以后的迭代开发留下错误隐患。因此代码*其实是既能够降低bug数量，还能无形中提高开发效率的。有时过于追求效率而忽视代码审查反而会欲速不达。
问题4
《构建之法》第二版9.4节中介绍了PM（项目经理）的能力要求，其中的专业能力主要包括理解和表达能力，书中并没有提到与编程相关的能力。
我认为项目经理重要的一部分责任是与开发人员沟通，所以项目经理最好有一定对开发工作的了解，或者有一定开发的经历。这一点书中没有提到。
这个学期的团队项目是必须要有PM（项目经理）的，在整个团队项目中，PM虽然不需要写代码（当然很多组由于一些原因采取了轮换PM或者让PM也参与一部分开发工作）但是PM需要带领团队成员开例会，设计产品，管理产品的进度等工作。因此我认为PM一定需要对产品中的开发工作有较深的了解。
问题5
《构建之法》第二版15.1.3节中介绍了Bug会诊的相关内容，其中提到
> 项目接近尾声时，要确保门槛越来越高。今天的“Must”（超过门槛的修复）必须比昨天及以前的”No“的严重性要高，这样才能不断地提高系统的稳定性。
书中在下边的对话中提到，随着门槛提高，会有更多的Bug留在软件中，也提到了很多关于Bug的材料会被会诊说”no“，好像努力白费了一样。
书中回答到了，这样有利于软件的稳定性，以及可以将一些代码修改放到其他分支中。但是我觉得这些Bug可能仍需要在之后的版本中更新修复，那为何要在会诊中反复决定对一个Bug修改方式呢？
在这学期的团队作业中，我们确实在开发过程中遇到了一定数量的Bug。其中确实有一些bug的修复有可能会造成其他问题，我认为如果对于比较细微的bug，而在改动时却又有可能造成一些其他问题的话，确实可以选择暂时不对这个Bug进行修改，有利于产品稳定性。
新的问题
问题1
如何在对软件产品做出好的设计？
在团队项目开始时，每个团队都写了一些功能规格说明书。但是产品的内部设计（如数据库如何设计，前端页面的布局设计）等内容，仍然需要团队成员共同商议。如果把设计工作全部放在开始之前来完成，有可能会出现开发过程中由于实现难度或者想法改变等一些原因而修改设计，导致做一些无用功；而如果一边开发一边设计，又可能造成最终的产品设计风格不统一，效果不好的问题。
问题2
如何标准化衡量团队成员的贡献？
这门课程的团队作业需要衡量每个成员的贡献，作为评分的一部分，我所在的小组采用的是自评和互评来确定每个人的分数。但是实际上软件项目经常是由企业的团队完成的，贡献度的衡量涉及到企业绩效考核等环节，这些企业团队内部的贡献衡量显然要比这个课程作业中复杂，那么企业中的衡量标准又是一什么方式制定的呢？
学到的“知识点”
需求
在需求阶段使用NABCD来分析需求，有助于清晰地梳理出用户需求
设计
要把一些基本框架设计好后在开始工作，比如前端页面的布局，后端数据库设计和前后端接口等内容应先设计好，在以后的工作中尽量不要做大的改动
实现
实现阶段团队成员要多做沟通，可以交流后续的工作方案和目前实现阶段遇到的突发状况，以调整根据需要开发计划。
测试
测试人员和开发人员要及时沟通，在测试有问题的时候即使考虑对策，如果对用户影响很大就尽量修改，如果是比较细微的错误，也可以考虑为了维持项目的稳定性暂时不修改。
发布
发布时要尽量做宣传，宣传有助于提高活跃用户数量
维护
建立反馈机制，如用户交流群，或者在软件中保留问题反馈部分，可以及时的发现问题解决问题。
自己的理解或心得
在双人项目中体会了一遍结对编程，结对编程最大的感受就是，与两个人独立工作相比，结对编程确实能编写出质量更高的代码，有可能达到1+1>2的效果。
团队项目中整个团队合作完成了一个小型的项目，大致体会了一遍软件开发的基本流程，从设计，实现，测试等环节都经历了一遍，我认为这是一次难得的体验，这段经历提升了我的编程能力和经验。
这是这门课最后一次作业了，祝看到这里的同学/助教/老师暑假快乐