[I.3] 个人作业：结课总结

[I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个工程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.2] 个人作业：软件案例分析
我在这个课程的目标是	熟悉软件开发流程，丰富软件开发经验，提高软件开发的团队合作能力，掌握优秀的软件开发方式
这个作业具体在哪个具体方面帮助我实现目标	对软件工程课程进行系统性总结

链接到以前提问题的博客

[I.1] 个人作业：阅读和提问

对自己曾经提出的问题进行解答

1.代码复用在实际开发中是否总是有效的？那么如何判断哪些代码适合复用？有没有一种通用的代码复用策略来避免复用出现的问题？

代码复用确实是提高开发效率的重要手段，它可以减少重复劳动、提高一致性并节省时间。然而，我在项目实践中还是遇到了那类问题：复用不了解的代码导致调试困难。例如，我们在课程小组项目中尝试使用某个开源组件进行数据格式转换。虽然该组件有文档，但由于对它的输入前置条件和边界值理解不深，导致集成后出现一些异常行为，而这些问题难以复现，也难以定位。

如何判断适合复用的代码？我通过查阅 Martin Fowler 的设计文章和一些架构设计书籍，我总结出以下几点作为判断标准：

• 低耦合高内聚的模块优先复用；
• 有良好文档与单元测试支持的代码；
• 能被独立部署或替换的服务更适合复用；
• 通用性功能（如工具类、数据结构）比业务逻辑更适合复用；

若不了解语境，宁愿重写也不要盲目复用。

后来在团队开发中，我们为复用的模块统一编写接口使用说明文档和边界条件清单，也规定了必须写一组测试用例才能进行接入，这样显著减少了复用带来的问题。

2.如何正确的选择代码重构的时机？

我最纠结的是什么时候该重构代码。因为一重构就得改很多地方，怕出 bug，而且会拖延项目进度。我印象最深的是，在做课程项目时，为了加一个小功能，我要在原来的代码上改半天，因为一开始结构设计得不太合理。虽然最后做出来了，但代码变得更乱了。于是我当时想，要不要干脆重构一下？但那时候又快截止了，时间根本不够。

后来我明白了，不是所有时候都适合重构，得看项目的状态和时间安排。我现在的一些判断标准是：

• 如果一段代码总是要改，而且每次改都容易出错，就值得重构；
• 如果只是为了加一个新功能，不影响其他部分，先写出来再说；
• 有时间空档，比如功能做完了但还没交，就可以适当优化结构。

另外我学到一个挺实用的建议：把重构分成小步走，比如只重构一个模块或者只优化一层逻辑，这样风险会小很多。

3.在远程开发环境下，如何高效地进行团队协作

其实最后我还是没有完全的找到解决的办法，线下合作的效率还是远远高于线上。不过使用飞书发布任务、使用apifox进行接口设计等还是对于团队合作的效率提高有很大帮助。

4.在小团队中有效实施CI/CD

我觉得对于小团队来说，CI/CD 不一定要全套都做，但可以挑重点来：

• 自动运行测试；
• 自动构建（前端打包、后端编译）；
• 部署可以先手动，有条件再自动化。

CI/CD 不在于有没有钱搭系统，而在于有没有意识控制质量。

5.软件开发中的测试驱动开发（TDD）是否适合所有类型的软件项目

我试着在一个数据处理脚本项目里搞 TDD，也就是先写测试再写代码。感觉刚开始确实效率很低，因为还不习惯写测试，而且有些测试场景根本想不到。但一旦写好，后续改代码就放心多了，跑一遍测试就知道有没有问题。但是我也试过在前端页面开发中用 TDD，结果非常困难，因为 UI 的交互、动画太多，不好写测试。最后我还是放弃了这部分的 TDD，用手动测试配合快照测试代替。

结论：

• TDD 更适合逻辑复杂的部分，比如算法、数据验证、接口层等；
• UI 和快速迭代的项目不适合 TDD，但可以后期加入测试保证稳定性；
• 如果一开始来不及做 TDD，也可以等项目稳定后再加测试，逐步引入。

在项目的 需求/设计/实现/测试/发布/维护 阶段中都学到了什么“知识点”

阶段	学到的“知识点”
需求	在项目开始时，我们总是很容易陷入“我要实现什么功能”，但真正困难的是搞清楚用户到底需要什么。从用户的角度去写需求，而不是从开发者的视角想功能，才是更贴近真实需求的方式
设计	学会了使用如墨刀等工具进行ui设计，掌握了规格化设计的方法
实现	掌握了使用taro+vue开发微信小程序的方法，学会了用git等工具进行团队协作开发
测试	在测试阶段我们尝试编写单元测试，对核心函数进行输入输出验证。这让我理解到：测试不只是“点点页面看看有没有错”，而是要系统地验证功能是否正常工作。
发布	尝试使用 GitHub Actions 做自动构建和测试，每次提交代码都会触发一次自动流程。虽然最终没有完全使用CI/CD,但大致掌握了CI/CD的流程和方法
维护	项目完成后，有些功能需要小改动，我们才发现代码耦合太严重，改一处牵动全局。于是我们进行了代码重构，比如提取函数、模块分层。维护不是简单修 bug，而是不断优化代码结构，让项目更容易修改和扩展。

心得与体会

这次的团队项目，是我第一次尝试小程序开发，更别说是第一次接触这种贴近生产环境的团队协作开发方式。在开发中，我几乎从零开始学习如何使用taro框架开发小程序带如何使用git进行团队协作，这让我的开发技术有了很大的提升。

在软件设计阶段，我总是从开发某个功能是否容易作为起点来评估设计，一味的追求开发效率，却忽视了用户体验的重要性，导致我们的第一版设计虽然简单，但是却有很糟糕的用户体验。这让我意识到了以用户视角来进行设计的重要性，先将用户体验放在首位，一个功能如果做出来对用户是负体验，那么宁可不做。

在后面的代码实现阶段，我们也遇到团队协作方面上的困难，明明是简单的需求，却因为较低的交流效率导致功能始终无法成功对接，大大降低开发效率，不过这也让我们在不断的试错中提高了团队协作进行开发的水平。

这次团队开发，我最大的收获不是技术，而是“做中学”的成长方式。软件工程不是单靠书本就能学会的，只有真正参与进去、和队友配合、踩过坑、交过付，才会懂得每个阶段的价值。