罗杰软工个人作业-提问回顾与个人总结

罗杰软工个人作业-提问回顾与个人总结

Part 1 前言

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程
这个作业的要求在哪里	个人作业-提问回顾与个人总结-CSDN社区
我在这个课程的目标是	1. 掌握撰写清晰简洁的博客的能力 2. 体验完整的项目开发的流程 3. 熟练使用git协作开发
这个作业在哪个具体方面帮助我实现目标	掌握撰写清晰简洁的博客的能力

• 教学班级：周四班
• 提问链接：(55条消息) 阅读《构建之法》并提问_20373892-周奕龙的博客-CSDN博客

Part 2 对自己提出的问题回答

1、TDD（测试驱动开发）对于敏捷项目的开发有何突出的地方？

之前我提出这个问题的时候是因为之前没有接触过TDD模式，与个人经验不符。本次软工项目的开发中我们也采用了经典的需求-设计-实现-测试的开发流程，结合在开发测试过程中遇到的问题，以及书上对于TDD的描述，我认为TDD开发模式还是有很多可取之处的。

首先，我之前所理解的TDD中的测试样例局限于自己经历过的单元测试和场景测试，但实际上测试样例应该是在充分考虑了整体需求之后所设计的，是对预期功能完成度的一种检验。完成了功能模块的测试也就意味着实现了对应的需求。

其次，TDD要求编写可测试的代码，这通常意味着代码需要更好地组织和模块化。通过在编写代码之前先考虑测试的需求，开发团队能够更好地设计代码结构，提高代码的可维护性。我们小组在实际开发的过程中由于alpha阶段架构的问题进行过几次小的重构。这是因为作为一个敏捷项目，在alpha阶段我们为了快速实现一个可用的版本，对于架构的设计并没有过多的思考。然而若使用TDD开发模式，实现规范好各个部分的测试样例，引导框架开发，可能会有所改善。

2、在敏捷开发中，团队文档应该如何规范、简明地撰写，便于对项目进行跟踪？

1. 文档应该使用清晰的结构和格式，并且多用表格、图片表达信息。如对于团队贡献度和每个人的阶段性任务可以使用表格，对于团队的阶段性成果展示可以多用图片等，使文档易于阅读和理解。
2. 文档的受众一定要明确。受众一般可以分为团队开发人员和实际用户。对于技术人员，一定要讲清楚技术的细节，如代码规范，变量定义规范等；对于用户，应该使用简明扼要的语言来解释概念和功能。我们团队在实际开发和后期宣发的过程中就出现了相应的问题，针对技术人员的文档没有明确的要求，开发人员不知所以；交给用户的文档冗长，信息量少。
3. 一定要及时更新和维护。随着项目的进行，文档应该及时更新和维护，以反映最新的项目状态和需求变化。确保文档与实际代码和功能保持一致。在我们小组实际的开发中，PM的文档协调沟通不到位，导致后期实际开发中的需求变动都没有体现在文档中，导致PM最后自己都不明确我们到底开发了什么功能。
4. 选择适当的工具和平台来编写和分享文档，如腾讯云文档等，不过我们小组在开发过程中对于文档的维护较少，基本是开发人员在Apifox上频繁维护接口文档。

3、频繁的重构是否必要？有这个时间为什么不设计一个可扩展性强的设计架构满足可能的需求？

首先说结论：现在我认为是必要的。

设计一个可扩展性强的架构固然重要，但在项目一开始时往往难以拿出一个完美的设计。况且敏捷开发强调迭代和快速交付。在这过程中可能需求随时会发生变化，并且随时会有用户的反馈，通过频繁的重构，可以更好地适应变化的需求，保持代码的灵活性和可维护性。

4、在结队编程中，若两人特长不一样，此时轮换“驾驶员/领航员”角色是否有必要？

首先说结论：现在我也认为是有必要的。

我认为对于我们罗杰软工这个课堂，结对编程更倾向于一种体验而不是单纯为了写一个单词链的项目。其实结对编程的目的之一就是促进团队合作和沟通。在我和林子杰同学结对编程的过程中，通过轮换角色，团队成员可以更好地了解彼此的思维方式和工作方式，这是一种教学相长的方式。而且轮换“领航员”方便我们对代码都有深入了解。虽然在分工上我主要负责核心算法的开发，林同学负责UI界面的展示，但是通过理论换角色，我们对于不同模块的代码都有了解，对接起来十分方便。

5、单元测试是否应该代码作者一人完成？

首先说结论：我现在认为这个是团队的任务，不应该由作者一人完成。

第一，不同的开发人员有不同的思维方式，可以从不同的角度来编写测试用例，覆盖更广泛的代码路径和场景，这有助于发现更多的潜在bug。

第二，团队中的其他成员可以参与代码审查，包括开发代码和测试代码，帮助改进测试质量和覆盖率。我们小组在单元测试中就是通过团队审查，发现了部分前端的请求代码没有使用try…catch语句，导致了一些奇怪的bug。

Part 3 在实践中学习知识点

需求阶段

对于需求的讨论、确定一定需要一个拍板人。

不论本次罗杰软工的随意选题，还是将来实际软件开发过程中和客户协商需求，团队中一定需要一个拍板人，这样可以避免很多无效的沟通和讨论。

在我们alpha阶段确立需求时，一晚上一个会开了4个小时，从图书馆开到新北食堂负一，最后每个人的方法都没采用，临时新想了一个方案，我认为这是非常低效的。团队中需要一位果断的决策者，能够综合分析各个提案的好坏，并且一定要有最终的话语权，实在是不可像我们一样和稀泥。

设计阶段

在设计阶段，我们了解学习了MVVM架构，用于构建用户界面（View）和业务逻辑（Model）的分离，这可以使代码的分层更加清晰，视图与业务逻辑分离，视图开发人员和业务逻辑开发人员可以并行工作，减少彼此的依赖性。

实现阶段

我在实现阶段进一步学习了Vue3框架，并且学习使用了eslint规则和Prettier代码格式化。并主要学习了对于使用git协作开发的规范，包括但不限于对于分支的维护、利用actions进行CI/CD等。

测试阶段

因为我们的项目规模较小，我们主要学习使用了场景测试。通过为不同组员分配不同的角色，模拟体验项目的不同功能来发现bug。场景测试能够真实地模拟使用情况，并且涵盖了多个功能模块和交互过程，可以发现模块间的集成问题和潜在的冲突。

发布阶段

对于前端项目的发布，我们主要使用了github的CI/CD进行持续部署和发布。通过组员张启立同学对actions的脚本配置，实现了将dev分支合并到main分支时可自动打包部署到服务器上，大大减少了我们的工作量，方便我们版本快速迭代。

维护阶段

在维护阶段对于文档的管理非常重要，对于用户反馈的bug或意见要提提issue，多做记录；对于新加的功能也需要及时在产品发布说明书中体现。

Part 4 反思与感悟

个人项目

首先是阅读并提问，我在这次作业中学习到了如何快速入门一个新领域。通过阅读一些权威文章、书籍，并对自己不懂的问题提问的方式，可以帮助我更好地了解一些基础的信息。在将来我科研的阶段势必也会遇到类似的问题，譬如课题组的老师给了一个方向，我就可以先通过阅读经典论文的方式找到几个关键词，再针对这些关键词以点概面深入了解，想必事半功倍。这种边看边提问，边思考的方式非常适用于泛读。

结对编程

结对编程的开发过程没什么好说的，队友林子杰同学非常给力，两人的合作过程非常愉快。两个人各司其职，我贡献了主要的算法，也从结对中学习到了代码性能分析相关方法和代码开发规范。与自己优势互补的伙伴一起开发的经历真的太愉快了捏~

团队项目

团队项目的开发过程就不是非常愉快，我们小组的成员可以说对于PM都颇有微词。总的来说PM应该背大锅，因为他自己的任务并没有很好地完成，却需要我们一起背锅。但正如助教事后与我们讨论的，我们既然是一个团队，我也要承担一部分的责任。事实上，在PM失职的那段时间里，我们小组的其他成员没有人主动承担起沟通前后端的责任，我个人的想法也是完成自己这部分的任务就好，这是非常没有团队精神的做法。不管怎样，我也是团队的一份子，除了个人的责任之外，我也要为团队的健康运行多做考虑，这并不是我的分外之事。