个人作业-提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2023 年北航软件工程
这个作业的要求在哪里	个人作业-提问回顾与个人总结
我在这个课程的目标是	学习软件开发方法，了解并实践一些软件工程的方法论和工具，积累以结对编程和敏捷流程进行软件开发的经验，最终深刻掌握软件工程的能力。
这个作业在哪个具体方面帮助我实现目标	回顾之前的问题，反思本学期的学习成果，加深对软件工程的理解

一、阅读提问回顾

问题链接：软工个人作业-分析与提问

二、对问题的解答

1. 为什么单元测试必须由程序的作者来写？

首先先说一下单元测试，单元测试是对软件最小功能单元的测试。在实际的软件中，在分工下，每个人实际的工作相对独立，因此对于具体模块的细节只有编写者最为熟悉。代码的作者最熟悉每个功能单元的逻辑、效果和缺陷，因此由它们来编写单元测试更有可能通过单元测试找到代码中的问题。

对于作者自己没有考虑到的问题，恐怕较为细节，其他作者可以在代码复审部分检查，而不是帮作者编写单元测试。本着自己对自己的代码负责的态度，作者也应该自己编写单元测试。如果想要多重保险，可以在代码复审和功能测试上让其他人帮忙把关。

2. 如何界定“技能”与“解决问题”？

这一部分我想从本学期项目让我感触最深的事前调研和具体工作的角度进行分析。根据我本学期的经验，事前调研，判断工具和资源是否能满足我们的需求，以及学习这些工具，是一个非常耗费时间、贯穿整个项目、非常消耗脑力、具有一定风险的问题。在本项目中我负责的是评测机和部分评测后端，对于后端，只需要对 gin 框架和 SQL 比较了解，就可以轻松写完不少 API ，这些 API 大同小异，基本是纯粹的工作量问题。但是在评测机部分，由于我们为了安全要使用 docker 进行隔离，所以我们先花费了很多时间调研 go-docker 的 API ，然后由于我们的 CI-CD 也是使用 docker 进行部署，因此我们还需要配置 docker-in-docker ，而这些在网络上的资料非常少，甚至官方文档也很不清晰，因此一个简单的挂载目录和 docker 多阶段构建就花费了我很长时间的调研，但是这些都是低层次问题，我们真正的核心问题是评测机的逻辑。虽然未来工作中不一定会遇到这么多从头学习的知识，但是如果这些都能提前掌握，那么一定会对项目的进度和质量有很大的帮助。

3. 敏捷的团队如何自组织？

我们团队的分工策略大致分为前期基本分工和后期具体任务分工。对于前期的基本分工，会由 PM 根据大家之前的开发经验，结合对新工具的调研进行分工。这部分分工比较粗略，可以大致分为前端和后端。在实际过程中，会先划分任务，然后结合具体任务和各个任务的进度，既有每个成员自己选择尚未完成的任务，也有 PM 为目前没有任务的成员安排工作等部分。经过本学期的项目我觉得这样的组织还是很有可取之处的，它让管理层不必关心每个具体的任务由谁负责，而是由更底层的小团队自主完成。同时也促进了某项功能的子团队内部的沟通和协调，还是可以提升总体效率的。尤其是可以对具体情况快速反应，比如某个人的任务完成了，可以快速安排新的任务，而不是等到所有人都完成了才安排新的任务。这些可以总结为“大事统一，小事自主”。

4. 如何安排会议周期和时长？

我觉得会议不要过于拘泥于形式，比如说哪天开多长时间。我们队的策略是在会前就整理好需要讨论的所有的问题，然后在会议中依次讨论这些问题。同时，我们的前端和后端包括评测端还会在会前进行小组内部的讨论，然后在会议中进行汇报。这样的会议形式可以让会议的效率更高，也可以让会议的时间更加灵活，同时，这样的会议形式也可以让会议的内容更加丰富，不会因为时间不够而无法讨论完所有的问题，也不会出现其他人在讨论而有人无事可做的情况。这也很符合敏捷开发的理念。

5. 能否修改冻结的部分？会产生什么影响？

这个问题我的看法是具体问题具体分析。因为根据实际项目的开发，尤其是前后端衔接，要改动之前完成的部分工作的情况还是经常发生的。更何况实际发布后可能还有 A/B 测试或等待用户反馈改进功能等等，这些都需要对之前的工作进行修改。不过如果修改的影响较大，那么就需要重新进行测试、复审等等。这个问题的答案也可以从敏捷开发的角度进行分析。敏捷开发的核心是快速迭代，当然在开发前的设计也至关重要，如果确定功能进入稳定状态，可以将其“冻结”。

---

我没有还不明白的新问题。

三、学到的知识点

需求

需求方面我了解了 NABCD 需求分析。NABCD 需求分析是一种需求分析的方法，它将需求分为五个方面：Need（需求）、Approach（方法）、Benefit（收益）、Competition（竞争）、Delivery（推广）。这五个方面可以帮助我们更好地分析需求，从而更好地进行项目管理。

我们在选题的时候使用了 NABCD 分析来对组员提出的各个选题进行评价，最终选出了我们的项目，同时也为之后的开发指明了方向。

设计

我觉得设计最重要的是注重设计的合理性，而一个经典的思想就是面向对象的高内聚低耦合的思想。在我们的项目中，整个框架分为前端后端评测端，它们通过事先约定的 API 进行交互，这样就可以保证各个部分的独立性，同时也可以保证各个部分的可扩展性。这样的设计也可以让我们在开发过程中更加专注于自己的部分，而不用过多地关注其他部分的实现细节。

在设计 API 时，我们也考虑了 API 的效率和可扩展性，这样设计出的整体架构还是比较合理的，也极大地减轻了后期的工作量。

实现

实现部分就是具体的工作了，既包括 go 语言 gin 框架、docker 的操作、CI-CD、数据库操作等等具体知识，也包括如何进行代码规范、如何进行代码复审等等具体的软件工程过程细节。

测试

我了解了各种测试的特点和适用场景，比如单元测试、功能测试、压力测试、验收测试等等。在我们的项目中，这些测试我们也都尝试使用。在测试中我积累了很多开发过程中常常出现的问题，比如如何进行错误处理。我负责的评测机是一个复杂脆弱而又强耦合的系统，同时他又要面对各种各样的提交，如何合理地处理所有错误（不规范的提交）而不出现问题是一个很大的挑战。在这个过程中我积累了很多经验，也学到了很多知识。不得不说 go 语言的错误返回真的是有些麻烦，可能是我对 JAVA 的 try-catch 机制比较熟悉吧：知乎 - Go 语言的错误处理机制是一个优秀的设计吗？。

发布

由于我们的项目是一个 ToG 的项目，因此在发布时不必过度纠结宣发等等细节。我们也进行了宣传和收集反馈等等工作，也进行了开发到生产的整个流程。

维护

由于前面所述评测机的脆弱，我自从评测机第一版完成一直在处理各种 bug 和崩溃，我深刻体会到日志的重要性，从只有错误信息，到使用 go 日志文件等等，日志极大地帮助了我定位具体问题，同时也帮助我更好地进行错误处理。同时我在评测机中设计了生产和开发快速切换的机制，在开发模式下会额外保存很多信息帮助确定问题，而两者的切换仅需简单修改一个配置，极大简化了维护的工作量。

四、个人总结

我觉得前面在各个部分的收获中我已经总结得差不多了。通过本学期的软件工程课程，我对软件开发的流程和规范有了更深刻的理解，也对软件开发的分工和协作等等有了更深刻的认识。我在本课程中收获了很多，相信这些收获会对我今后的学习和工作有很大的帮助。