| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春北航计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 系统学习软件工程相关知识并进行实践。 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾学期初提出的问题，总结本学期的软件开发实践。 |
以前提出的问题
软件工程 - 个人博客作业
尝试解答
如何进行高质量的单元测试？
Q: 作者在2.1节 单元测试 中提到了单元测试失效的几种情况。在笔者实际使用单元测试中，尽管能够对代码进行覆盖测试，但是总觉得一些简单的单元测试无法对代码的所有运行逻辑进行测试(例如：循环、函数间逻辑)。此时应当如何学习编写更高质量的单元测试代码呢？
在软件工程的项目中，笔者主要负责了前端的工作，在测试上也主要使用功能性测试。在实际的合作编码过程中，我们发现，实际上大部分的bug在进行模块的演示过程中都能够被发现。
因此，我认为前端的高质量单元测试的要点在于合理的模块分割和定义好期望要求。对模块任务进行合理的分割，让每一部分都是一个可以独立运作的模块，这样有利于对任务进行划分(每个单元有具体的权责分配)，也有利于模块的演示。
在编码前讨论定义好期望要求，一方面能够在讨论的过程中共同决定好实现的具体思路，有利于高效开发，另一方面也在编码前对期望的功能进行了具体的规范，在测试过程中按照期望的功能逻辑进行演示就可以了。
例如，我们组在开发文献管理界面时，需要定义一个drawer，我们便共同决定了这个drawer的实现思路，并定义好的其预期功能(如打开效果，数据同步状态，关闭/取消效果，提交效果等)。在测试过程中，对这些功能进行逐一演示便能够发现大部分可能会存在的问题。
结对编程真的更高效吗？
Q: 作者在书P86提到，结对编程可以取得更高的”投入产出比”。我认可结对编程可以有效提高代码质量，但是我认为合作的效率更好。 1. 二人合作是4只手在编程，从速度上讲比结对编程更高，能够快速实现已经制定的目标；2. 结对编程面临二人技术能力不同而可能导致的一人编程、另一人参与度较低的情况；而二人合作可以通过任务量分配差异来规避此问题。3. 结对编程主要特点是二人不断交流、不断互审，那么二人合作也可以进行不断交流和审阅。因此，我认为结对编程的“投入产出比”可能不如合作编程。
在本学期软件工程的课程上，我也有幸尝试了结对编程开发方法。经过实际体验，我认为结对编程的效率是高的，因为开发效率不等于敲代码的速度。
如果单纯看代码录入的速度，那么结对编程的效率一定是不如分工编程的。但是，开发绝不是只有编码，结对编程可以大大提高代码的质量，减少之后修bug等工作的时间，从总体上看是能提高效率的。
新人如何融入敏捷团队？
Q: 作者在第六章介绍了敏捷开发，敏捷开发注重人员之间的沟通，能够有效增加开发进度。
但是敏捷开发对于团队的要求较高，如果团队人员流动较大，不熟悉项目的新手如何能较快地融入到敏捷开发的团队中呢？
在本学期的软件工程开发过程中，我们也经历了转会，有新的同学加入了我们的团队。新同学主要的融入方式我认为是首先和以前的开发同学进行合作，共同负责一个较大模块的开发，之后在熟悉项目后逐渐负责一个模块的开发。
文档的维护可能是敏捷开发的通病，文档的更新可能会有一定的滞后性，所以新人不能完全依靠文档来接手项目，但是敏捷开发对于人员之间沟通的注意能让每个开发者都比较熟悉项目内容，那么由开发者指导新人 是比较合适的。
该不该立即回团队成员email？
作者在这里提供了一些非常有用的建议，例如集中处理Email，微信等。
那么我们在开发过程中，如果有团队其他人员的相关问题，是否应当及时回复呢？如果不及时处理，可能会影响团队其他人员的进度；而及时处理又可能耽误自己手头的工作。
我们对项目成员的问题要进行分类，对于非常紧要的问题(阻碍该成员进度推进的问题)，我们可以进行较快的回应；而对需要上手修复的bug或者其他问题我们可以选择性的集中处理。主要原则是不耽误自己的开发进度，也在最大程度上帮助团队成员提高开发进度。
BUG应该立即修吗？
作者在11.5.5节讲到一个比较有意思的事情“小强地狱”，即bug积攒数量到一定程度的队员要使bug低于阈值才能继续开发；作者在后文中也提到一些小bug可能导致功能重写。
在自身的开发中，我也出现过由于一些之前的bug没有及时修复，导致后续需要大量时间重写某些功能的情形。那么，我们是对于出现的bug，是应当发现一个立即消除一个吗？修bug而影响的开发进度是否值得？
bug不一定要理解修复，但是issue要开好。
对bug进行分类，影响开发进度和功能的bug是需要尽早修复的，而其他的小bug可以等开发阶段结束后集中处理。在开发过程中，我们要利用好Github的issue功能，对发现的bug进行记录，以便后续集中修复。
为什么创新拓展不被接受？而“线性拓展”有着更好的命运？
作者在第16章谈到，
在算法和数据库领域，创新的想法一开始往往不被接受，而那些在前人基础上的“线性拓展”则往往有着更好的命运。而这些决定还是很有经验的期刊审稿人做出来的。在学术研究时，很多时候我们在工作中都需要和前人相似的工作进行比较，这样的work才可能更受认可。但是有时创新的一个小领域，便可能会因为别人无法对其进行判断而被忽视。是否应该根据前人的工作判断我们的工作的价值呢？如何避免创新拓展被忽视的情况出现？
在科研领域，"线性拓展"的工作因为可以和前人工作进行比较，这样的工作也更好去评价他的价值。创新拓展由于其可能存在的不确定性可能难以受到足够的重视。当然好的工作一定会发光，我们在进行一些创新性的工作时，也可以在某些维度上和已有的工作进行比较，来说明创新工作的优越性。
新的问题
我们本学期由于客观原因是进行了远程开发，由于无法进行每日立会等，敏捷开发过程中沟通的效率可能没有面对面编程高。不知道在远程开发的环境下，敏捷开发方法是否适用？或者要进行哪些方面的改进呢？
软件工程知识点
-
需求
- NABCD分析法：即从Need、Approach、Benefit、Competitor 和 Delivery 六个方面，全面分析目标用户；
- 在和目标用户交流的过程中，需要注意引导和挖掘目标用户对于产品的需求；
-
设计
- 自顶向下：从目标产品的最终形态和功能出发，分拆具体的子模块；
- 前后端分离：前后端分离设计，通过接口调用进行通信；
-
实现
- 利用Git进行代码维护，并保持主分支为可以构建的代码，进行每日构建；
- 使用Github的相关功能：如issue和commit进行关联等
-
测试
- 后端进行单元测试
- 前端进行功能性测试
-
发布
- 开发过程中不断记录出现的bug，在发布前一并修复
- 对软件整体进行压力性测试
-
维护
- 注意收集用户反馈，对用户反馈的bug进行处理
理解和心得
个人项目
在个人项目中主要熟悉了Github进行源代码管理的使用，对问题的分析、拆解和具体编码实现过程。
结对编程
结对编程环节我们体验了二人结对时如何进行交替分工、代码复审、共同确定编码思路。这一阶段主要锻炼了我在开发过程中的交流能力和合作能力。尤其是在远程结对的过程中，如何进行高效沟通和远程配合，对最终完成的代码质量有着重要的影响。
团队项目
在能力方面，团队开发的过程中锻炼了我的快速学习能力，在学习中实际上手开发。在软件工程方面，我实践了设计和实现环节中的一些方法，如Git & Github的使用，自顶向下逐级拆分的设计方法等。在团队合作的过程中，我锻炼了合作能力，只有和队友的有效沟通，才能维持项目的进度不断推进。
在实际团队项目的过程中，也感受到了软件工程在控制软件质量和开发进度的过程中的重要性。在之后的软件开发中，也要继续实践在课程中学习到的知识，并吸收更多新的思想。