软工第四次作业——提问回顾与个人总结

[20372004刘畅]

软工第四次作业——提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程社区-CSDN社区云
这个作业的要求在哪里	个人作业-提问回顾与个人总结
我在这个课程的目标是	学习Web网页开发的后端技能，体验团队开发，锻炼团队协作沟通能力
这个作业在哪个具体方面帮助我实现目标	体验团队开发，锻炼了开发能力和沟通能力

链接到以前提问题的博客

提问题的博客

对问题的解答

问题一 是否应该避免使用goto语句？

函数最好有单一的出口，为了达到这一目的，可以使用goto。

这个问题在前两周结对编程的过程中就有所体会。在对命令行参数进行异常处理时，由于同时判断正常情形和异常情形下的参数组合，而且需要判断的情况比较多，在这样的情况下使用goto语句（goto error或者goto end），使函数有单一的出口（即在函数最后选择正常返回return或者抛出异常throw exception），会使代码可读性更高，而且将异常处理部分的代码统一放在error标签下，有利于对异常抛出信息的更改，而且每个条件分支下只需要关注当前分支所需要处理的事务。

因此，当一个函数可能有多个出口时，使用goto语句，能增加代码的可读性，减少重复性的代码编写和更改。

问题二 对于所给例子和结论的疑惑

在7.5节实战中的软件工程中，给文盲的二伯买眼镜、Cargo Cult以及团队AB处理任务的不同模式，三个例子并没有具体回答对软件开发的启发，而在最后以“证人誓词的精神”结束对话。

这三个例子放在一起，主要是想说明一下几点：

1. 在实战中，需要注意用户的实际需求与产品提供的功能之间的关联性，正确理解用户的需求。
2. 做好软件项目，离不开人、技术、工具和方法。在查询资料，借鉴其他团队项目的开发流程和经验时，需要抓住重点，盲人摸象似的照搬学习的效果并不是很好。
3. 在进行任务追踪、进度管理时，简单或复杂的方法在本质上并没有太大的区别，重点在于陈述“全部的事实”，只有不偏不倚，才能客观地分析团队效率。

问题三 在合作中我们如何能让时间估计不那么飘忽？

几个从来没有合作过的程序员用他们从来没有用过的技术去实现一个他们以前没有碰过的需求，他们的时间估计一定会很飘忽。

正如提问题的博客中所说的：我们的团队似乎基本“符合”了这个极端的例子。在本学期的团队开发过程中，先后进行了Alpha和Beta两个阶段的迭代开发。在前一个阶段中，由于彼此都不是很熟悉，对团队自身的能力以及个人的能力不甚了解，项目的推进很艰难。后来也是及时调整了团队的协作方式，认真做了功能需求的评估。

得出的重要结论是，需要重视功能开发前的调研阶段，查询信息、尝试开发，在前期准备工作中慢慢了解功能实现的步骤，这样估计的时间与实际花费的时间就不会相差很多。

问题五 如何理解修复Bug的门槛逐渐提高这一招数？

在Beta期间，修复Bug的门槛要逐渐提高，昨天修复了同类的Bug，今天如果还找到了类似的问题，团队未必要修复。

在提问题的博客中，我当时的观点是：Bug的修复应该是按照严重程度依次下降的顺序去逐个修复，如果当天修复完严重的Bug，要下班的时候只有如上所说“类似”的问题，那可以依据这个招数考虑不去修复。问题是：如果当天发现的Bug不多且不严重，那么对于这样的“类似”的问题，是否应该选择修复它，最后由会诊决定是否将修复集成到代码库中去。

在开发过程中，真实的情况是：首先对于基础功能而言需要保证其正确性，比如前后端的对接问题，不容出错，这是肯定的；其次，对于杀手功能的实现，既然要提高用户的满意度，那么一定不能有可复现的Bug遗留；最后，对于Web开发，Bug的严重性的一个重要指标在于出现频次，出现频次高的Bug一定需要修复。

在实践中学习知识点

软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” - 在实践中学习知识点。

• 请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点即可。

• 需求阶段：主动与队友沟通，一定要是线下的沟通！线上沟通的不确定性太大了，无法知道其他人具体的状态，究竟是在思考需求还是走神、游离于会议之外不得而知。另外，在团队意见一致的情况下，dream big！
• 实现阶段：明确任务划分，任务一定要分配到个人。在我们的Web开发过程中，我们团队是分了前端和后端两个开发分队。但是任务不应该只是按照前端和后端两个部分进行划分，任务需要精确到个人，每个人做的事情要明确，这样既能避免划水摸鱼者把任务全扔给别人做，也能避免和队友做了重复的工作。
• 测试阶段：1.保留测试样例，便于回归测试；2.任务场景以接口、函数的功能为依托进行编写。应该先明确要测试的接口和函数，然后以此为参照进行测试的流程，确保每个接口和函数的所有行为被测试到。
• 发布阶段：抓住目标用户群体。我们网站开发最初的目的是打造一个线上的课程学习平台，供老师、助教发布作业通知，供学生收到通知以及提醒（提醒是重点）、分享课程笔记、有需要地查询自己感兴趣的笔记。由于网站的目标群体主要是老师和学生，需要依托课程进行，所以在课程开始的前中期就应该发布一版较为完善的满足基本需求的网站，从而向老师和同学发布出去。但是由于前期协作开发的一些问题，我们的较为完善的版本发布较晚，导致在学期开始时沟通过的同意试用我们网站的老师在接近学期末才收到发布的网站，造成了一定的用户流失。
• 维护阶段：及时响应用户所反馈的问题。对于反馈的明显严重的问题，一定要及时响应，做修改，这一过程也需要将任务分到具体的成员手中。对于一些可能不影响正常功能的问题，也需要重视并修正，因为网站是给用户使用的，当一个用户提出一些使用上的问题或者困难时，一般其他用户也会有相同的体验，所以也应该及时反馈给用户，同时尽可能修正。

理解与心得

结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。

首先是通过阅读《构建之法》了解了很多有关软件开发的知识。这些知识不是具体的开发一个软件或者网站所需要使用的技术栈（这个相信我们系的同学也能通过查阅各种博客网站，在实践中就能学习到），而是软件开发的流程（从需求到实现的一些代码以外的事）、团队开发的管理方法。

结对编程中，”结对“的重心应该是两个人共同开发一份代码，”共同“不是分任务式的一人完成一部分，而是每一行代码都清楚，即便不是自己敲下来的也应该是自己看着敲下来的。但是在实际过程中，由于和队友并不是特别熟悉，而且平时的日常轨迹不重合，真正结对开发的时间是有限的。这个问题在之后团队开发中得到了改善，和后端的同学共同编写一段代码，而且熟悉对方写的代码部分，这也方便了后期的调试工作。

在团队开发中，沟通是第一位的。对于首次合作的团队来说，沟通尤为重要。我深刻认识到例会的重要性，虽然开会往往意味着低效率地沟通，但是在合理安排会议流程，明确会议的内容的情况下，会议起到的作用远大于在功能实现上的所作出的贡献。一个有效率的会议包含互相告知进度、明确接下来的任务分配、以及对开发日程的协商调整等部分。因此，在两次开发迭代阶段的两周至少七次会议要求是有必要的，我们不应该将其作为一种形式主义完成。