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

项目	内容
课程	2026春季软件工程
作业要求	个人作业：结课总结
课程目标	学会如何系统性地开发标准高效的软件，提高团队协作和实践动手能力
作业作用	总结这学期在软件工程这门课的收获

一、问题回顾与反思

问题一：关于"结对编程"的实际效益与适用边界

解答

经过本学期的学习和实践，我对结对编程有了更全面的认识：

1. 沟通成本与效益的权衡

结对编程的沟通成本确实存在，但其效益不能仅用"代码产出量"来衡量。通过阅读教材和课堂讨论，我认识到结对编程的核心价值在于：

• 知识共享：两人结对时，经验较少的一方能够快速学习到实践中常用的技巧和模式，这种隐式知识的传递在单人开发中很难实现。
• 即时审查：代码在编写的同时就被审查，缺陷在最早期就被发现，避免了后期昂贵的修复成本。

2. 适用场景的边界

通过实践和查阅资料，我总结出结对编程更适合以下场景：

• 高复杂度逻辑设计：涉及复杂算法或架构决策时，两人讨论能显著减少设计缺陷。
• 关键模块开发：如支付、安全等不容出错的核心模块。
• 新人培训阶段：帮助新成员快速融入团队代码风格和技术栈。

而在以下场景中，沟通成本可能超过效益：

• 简单重复性编码：如CRUD接口、配置文件编写等。
• 大规模并行开发：当项目需要多小组同时推进时，全面结对会导致人力分配捉襟见肘。

---

问题二：关于"猪/鸡/鹦鹉"模型的进一步思考

解答

1. 三种角色的职责分工

经过深入学习项目管理知识，我对这一模型有了更务实的理解：

• 猪：全身心投入项目的核心开发者，负责需求分析、架构设计、编码实现、测试等核心工作。他们是项目成败的直接责任人。
• 鸡：关心项目但不直接承担开发任务的人，如产品经理、用户代表、其他部门协调人。他们提供需求和反馈，但不深入日常开发。
• 鹦鹉：在组织中传递信息、影响决策但不直接参与的人，如管理层、顾问。他们可能不写代码也不定义需求，但通过资源分配和方向指引影响项目走向。

2. 协同与约束机制

通过这学期的团队协作以及查阅相关资料，我发现以下方式可以促进各角色之间的协作

• 每周例会：让猪和鸡都能了解进展，但只有猪承诺具体任务。
• 组内评审：鸡和鹦鹉在评审环节提供反馈，但不干涉开发过程中的技术决策。
• 产品待办列表：由产品负责人（鸡的代表）维护优先级，开发团队（猪）决定如何实现。

---

问题三：关于"软件估计"与"不确定性"问题的解决

解答

估计方法的价值依然存在

学期初我认为"软件估计的大误差在所难免，应更着力于处理误差"。经过学习，我修正了这一观点：

• 虽然大误确实难以避免，但估计本身仍然有重要价值。没有估计就无法制定计划、分配资源、设定预期。
• 好的估计方法虽然不能做到精确，但能将误差范围大大缩小，这对项目管理已经有很大帮助。

---

问题四：在AI辅助编程日益强大的背景下，反复练习底层代码是否还有必要

解答

底层练习仍然有必要，但侧重点应调整

经过一学期的学习和实践，我部分修正了学期初的观点：

• AI辅助编程确实强大，但它本质上是"放大器"——它放大的是使用者的能力。如果使用者不理解底层原理，就无法正确判断AI生成代码的质量，也无法在AI出错时进行修正。
• 在我们的课程实践中，多次遇到AI生成的代码存在逻辑错误、性能隐患或安全漏洞的情况，如果没有扎实的底层知识，很难发现和修复这些问题。

而邹老师提出的"反复练习形成肌肉记忆"这一核心理念我依然认同，但练习的内容应当与时俱进：

• 仍需练习的底层能力：数据结构与算法的应用、调试与排错能力、阅读和理解他人代码的能力、基本的系统设计和架构思维。
• 可以降低练习优先级的内容：特定语言的语法细节（如某个API的参数顺序）、模板化的代码编写（如标准的增删改查）。
• 应增加练习的高层能力：需求分析与问题拆解、系统设计、代码审查、与AI协作的"提示工程"能力。

---

问题五：如何平衡"代码规范"和"编程效率"

解答

代码规范不是效率的对立面

学期初我认为严格的代码规范会限制效率，现在我的理解是：

• 短期看，遵守规范确实会增加一定的编码时间（约5%-10%）。
• 长期看，规范带来的可读性提升、维护成本降低、团队协作顺畅所节省的时间，远大于编码时多花的时间。
• 一个不遵守规范的代码库，即使初期开发很快，后期也会因为"技术债务"而严重拖慢进度。

工具化是平衡的关键

通过课程实践，我发现现代开发中代码规范的执行已经高度工具化：

• 格式化器可以在保存时自动格式化代码，开发者几乎不需要手动调整格式。
• 静态检查工具可以在编码时实时提示规范问题，将规范内化到开发流程中。
• CI/CD流水线中可以设置规范检查门禁，在代码合并前自动验证。

这意味着遵守规范的成本已经被工具大幅降低，"规范vs效率"的矛盾在现代工具链下已经大大缓解。

---

仍然存在的疑惑

经过一学期的学习，大部分问题有了更清晰的认识，但仍有以下方面存在疑惑：

1. AI辅助编程对软件工程的深层影响：虽然我对"底层练习是否必要"这个问题有了答案，但AI对软件工程方法论的深层影响仍让我困惑——当AI能够自动生成大量代码时，传统的代码审查、测试策略、甚至敏捷开发的迭代节奏是否都需要重新设计？这是一个更大的问题，目前还没有清晰的思路。

2. 对于软件估计中的不确定性如何解决: 我理解了软件估计对于开发方向的确认仍有重要意义，但是真实工作中存在的不确定性使得较为精确的估计仍旧十分困难，几乎所有软件项目都始于愿景和模糊的基本需求，缺乏细粒度的细节和对边界情况的考虑。在项目推进过程中，随着对系统理解的加深或外部环境的变化，需求往往会发生变更或范围蔓延。这种不断演变的特性使得基于初期信息做出的估算极易偏离实际轨道。

---

产生的新问题

通过本学期的学习和实践，我还产生了以下新的问题：

1. 如何在学生团队中有效实践敏捷开发？ 在学生课程项目中，由于成员时间碎片化、技术水平差异大、项目周期短等特点，如何对教材中介绍的敏捷开发方法进行适当裁剪，使其真正发挥作用而非流于形式？

2. 技术债务的管理策略：在课程项目中，我们为了赶进度积累了不少"临时代码"，后期维护时付出了很大代价。在真实的软件开发中，技术债务应如何量化和管理？什么时机应该"停下来还债"，什么时候可以"带着债务前进"？

3. 软件质量的多维度权衡：教材中强调了软件质量的重要性，但在实际中，质量包含多个维度（功能正确性、性能、安全性、可用性、可维护性等），这些维度之间往往存在冲突。在资源有限的情况下，如何做出合理的优先级决策？

---

二、项目各阶段所学知识点

阶段	知识点
需求	需求获取与分析：通过与利益相关者沟通、用户访谈、场景分析等方式，将模糊的用户需求转化为明确、可验证的功能需求和非功能需求，并使用用例图、用户故事等工具进行规范化描述。
设计	模块化与高内聚低耦合：将系统划分为职责单一、边界清晰的模块，模块内部功能高度相关（高内聚），模块之间依赖关系尽量少且明确（低耦合），从而提高系统的可维护性和可扩展性。
实现	代码规范与代码复审：遵循统一的编码规范（命名、缩进、注释等）编写代码，并通过代码复审（Code Review）机制在编码阶段及早发现缺陷、统一风格、促进团队知识共享。
测试	测试分层策略：按照单元测试→集成测试→系统测试→验收测试的层次逐步验证软件质量，每一层关注不同粒度的问题，从函数级别的正确性到整体系统是否满足用户需求。
发布	持续集成与持续交付（CI/CD）：通过自动化构建、测试和部署流水线，使代码变更能够频繁、可靠地发布到生产环境，降低发布风险并缩短交付周期。
维护	技术债务管理：识别和记录因赶进度而做出的妥协性代码（技术债务），评估其对系统长期健康的影响，在适当的时机通过重构来偿还债务，平衡短期交付压力与长期可维护性。

三、课程总结

本学习软件工程课程的学习让我对一个软件从设计到开发到测试和维护的全流程有了深入的认识。首先在软件设计上，学期初的一项作业要求我们选定一个软件进行测评，通过亲身体验和采访同学等方式，从用户的视角去评估一款软件，进而认识到对于此类的软件用户最关心哪些方面。从中我深刻认识到软件的设计需要从需求出发，而非空荡的奇思妙想。之后在团队作业的开发过程中，不同于个人开发只需要在本地写好各个文件，在团队中每个人负责不同的模块，自身模块如何实现对于其他同学是透明的，因而模块之间的接口设计和接口文档的撰写就尤为重要，由此才能保证接口联调时不会疯狂报错。最后是开发完成之后的上线测试，不同于其他课程的大作业只需要简单跑出个效果，实现基本的业务逻辑，软工这门课需要我们切实地考虑各种功能需要进行的各种测试、各种场景下可能出现的各种问题，不仅功能要完善和正确，安全性和可靠性也需要重点考虑