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

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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[[I.3]] 个人作业：结课总结](https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR/homework/13465)
我在这个课程的目标是	学习并应用软件工程的方法论，掌握开发软件的先进工具，开发一款有趣的软件
这个作业在哪个具体方面帮助我实现目标	巩固课程收获，以便将知识应用于未来的开发实践中

---

提出问题的博客：[[I.1]] 个人作业：阅读和提问 - lu-yx - 博客园](https://www.cnblogs.com/justDoSomething/p/18759652)

一、问题回顾与思考

问题一、如何理解"The Opposite of Skill"是"Problem Solving"？

解答：

巴克斯顿说技能的反面是“Problem Solving“，作者引用该论点，并举例进行说明：

一个 IT 专业的大学生来面试， 简历上写“技能： 精通 Visual Studio C# 编程” ： 于是面试官请他用 Visual Studio IDE 写一段程序。 一个 “不精通” 的面试者的编程过程实际上就是一个 “解决问题” 的过程——

嗯， 怎么开始一个 C# 的命令行程序呢？
定义数组是怎么弄的？ 是 “int [] arr"还是"int arr[]“还是"ArrayList”, 还是"Array”。 哦， 我平时都是上网査的。哦，我不知道还有 MSDN 网站。
嗯， 为什么编译没过呢， 哦， 这里少一个分号。
嗯， 怎么设断点？ 怎么定义命令行参数？ 额， 我要査一査……

作者在例子中提出的问题都是基础型问题，由此可见，作者想要强调的是，掌握技巧才能不犯低级错误，避免在简单的问题上浪费时间。如果某人真的掌握了某项技巧，就应该能够流畅地、条理清晰地“完成任务”，而不是遭遇问题，然后被迫“解决问题”。

仍有疑惑：

按照上述理解，我认为作者的表达有些粗糙，应该进行更细致地说明。比如，“解决问题”可以涵盖大部分工作内容，即便是流畅地写出了一个完美的程序，也可以理解为是在“解决问题”，所以首先应该将这里提到的“Problem Solving”与广义的解决问题做一些区分；然后在举例后应该强调一些重点，而不是抛出一个例子但不加解释，留给读者猜测。这个观点是否存在更好的解释呢？

问题二、敏捷流程在Sprint结束后会遗留大量Bug，甚至存在设计问题，这种求速不求质的模式在后面验收时要花费大量时间，是否会导致整体开发效率更低？

解答：

通过开发实践，我对该问题有了新的理解。敏捷流程并不是“求速不求质”，遗留Bug在任何开发模式中都是在所难免的。此外，敏捷流程与阶段性的复查修改并不冲突。敏捷流程强调的是时刻关注需求、团队高频次的沟通交流，主要目的在于让团队高效组织，更灵活、更自律、更高效。

仍有疑惑：

在开发实践中，我们开发完一个功能后往往还需要反复微调，可这部分调整任务也会花去大量时间，所以应该怎么更高效地完成这部分任务呢？这是技术与熟练度问题，还是开发模式问题？

问题三、如何在商业竞争中始终保持某一功能的“杀手”地位？

解答：

通过网络调研和线下讨论，我对该问题有了新的理解。我们阻止不了竞争对手在自家产品上模仿我们产品的“杀手功能”，所以我们要从自身产品入手，做更多的差异化处理。首先，我们可以建立扁平化团队结构，以便快速响应市场需求并优化服务，并进一步将资源集中于打磨“杀手功能”，尽量扩大核心优势；其次，我们应充分考虑产品所处的市场环境，要根据所处的不同阶段以及竞争对手的优劣势选择适合自身的定位策略，在消费者心智中占据有利位置；此外，我们可以围绕该功能构建自己的生态，比如苹果通过ios生态绑定开发者资源，进而巩固了系统功能优势。

仍有疑惑：

无论是营销还是构建专属生态，都需要投入大量的资金和人力，而新生团队往往缺少资金和人手，当面对超大体量的资本碾压时，是否有更低成本的手段进行抵抗呢？

问题四、PM具有对于产品的商业化起到了至关重要的作用，是产品开发过程的舵手。当团队中没有一个突出的“牛人”作为领导者时，团队应该如何更好地合作？

解答：

通过敏捷开发实践，我对这个问题有了更好的理解。即便没有一个突出的“牛人”作为领导者，团队也可以通过会议的方式对大多数问题给出解决方案。团队最需要的是凝聚力和目标，具备了这两样东西后，团队就可以组织起有效的会议，进而解决问题，正所谓“众人拾柴火焰高”。我们在本学期的开发阶段，常常通过集体会议的方式来决定产品的特性，并进行分工安排。大家各司其职，开发过程较为顺利。

问题五、如何理解“在Beta期间，修复Bug的门槛要逐渐提高”？

解答：

通过网络调研，我对该问题有了新的理解。注意，问题中的“修复”指的是将修复后代码集成到Release版本库中。在商业化经营中，修复Bug要考虑人工成本、用户体验等诸多因素，并不是所有Bug都要立即修复。团队首先要回答Bug是什么、Bug的危害、解决方案评估、用户的变通办法、是否经过充分测试等问题。团队要明确修复通过的标准，而且这个标准往往要越来越高，这样才能不断提高系统的稳定性。

二、知识点总结

1. 需求阶段：学到 需求获取与分析技巧

在这个阶段，我学会了如何与用户沟通，使用用户访谈、问卷、场景描述等方式提取用户真实需求，并使用用例图和用户故事来明确需求边界，避免“需求蔓延”。

2. 设计阶段：学到 模块化设计思想

通过原型设计工具，以及绘制类图、顺序图等 UML 工具，我理解了如何将系统拆解为清晰、低耦合、高内聚的模块，并学会用MVC架构模式进行分层设计，提升了系统的可扩展性与可维护性。

3. 实现阶段：学到 代码规范与版本控制

在团队开发中，我学会了遵循统一的编码规范（如命名风格、注释要求），并熟练使用Git进行版本控制、分支管理与协同开发，有效避免代码冲突，提高开发效率。

4. 测试阶段：学到 单元测试与自动化测试

在此阶段，我们学到了单元测试的编写方法，并了解了持续集成中的自动化测试流程，从而在提交代码前就能及时发现问题，保障软件质量。

5. 发布阶段：学到 部署与发布流程

我们学会了将开发完成的软件打包部署到测试或生产环境中，掌握了 CI/CD 工具的基本用法，初步理解了从代码到产品上线的完整流程。

6. 维护阶段：学到 日志与监控机制

在系统上线后，为了快速定位和修复问题，我学会了设计日志记录机制、使用日志工具分析运行状况，并初步了解了如何设置异常报警与性能监控。

三、心得体会

1. 结对编程：沟通合作、互补学习

与同伴一对一结对编程时，我们坐在一起共同开发功能模块。这种模式让我认识到：

• 沟通与表达能力至关重要：解释自己的设计思路，听懂对方的问题，是高效协作的前提。
• 代码风格与思维方式的碰撞：对方常常用不同的方式解决同样的问题，从中我收获很多“原来还能这样”的启发。
• 即时反馈加速成长：当我出现逻辑问题或写出低效代码时，对方能立即指出并改进。

心得：结对编程不只是协作开发，更是一种“双向学习”的过程。

2. 团队项目：工程意识与责任感的养成

在多人协作的团队项目中，整个流程更贴近真实的软件工程开发。我逐渐意识到：

• 分工明确、接口清晰是高效协作的保障：设计API时必须考虑清楚边界条件、数据格式和异常处理。
• 版本控制与任务管理工具（如Git、飞书）是协作的必需品。
• 责任感与时间管理能力的提升：不仅要对自己的代码负责，还要对整个团队的进度负责。
• 文档与沟通的重要性：写好注释，及时同步问题，才能让项目顺利前进。

心得：团队项目让我真正体会到“软件工程”不仅是写代码，更是“与人合作造系统”的过程。

3. 总结体会

无论是结对编程的“互相促进”，还是团队项目的“协同工程”，都让我深刻认识到：

软件开发不仅仅是技术问题，更是沟通、协作、管理与责任的综合能力体现。

这些实践经历，是我学习软件工程课程中最宝贵的财富。