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

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

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	I.3 个人作业：结课总结
我在这个课程的目标是	接触、理解并应用现代软件工程常用的开发方式，锻炼自己编写代码以及团队协作的能力
这个作业在哪个具体方面帮助我实现目标	回顾一学期的软件工程实践，整理自己对工程流程、团队协作和项目质量的理解

一、回到最开始提出的问题

我在 I.1 里提的第一个问题，是关于课堂注意力、教师能力和课程必要性的。那时我有点疑惑：认真听讲训练注意力这件事是否适用于所有课程；一个人学术能力强，是否就一定能把课讲好。一个学期下来，我觉得答案应该更折中一点。注意力当然可以被训练，但不一定只靠课堂训练；课程也不能只靠“听起来有没有趣”来判断价值。软件工程这门课里，我真正理解很多内容，反而是在后面的个人作业、结对项目和团队项目中完成的。课堂提供了框架，实践才让我知道这些框架为什么有用。至于教学能力和学术能力，我现在仍然觉得它们相关但不等同，好的课程设计会把学生推到真实问题面前，而不是只把概念讲完。

第二个问题是代码评审。最开始我好奇的是，大公司里的代码评审到底是怎样保证质量的，如果一个大型项目没有合适的人 Review，新人又应该怎么上手。通过这一学期的实践，我对这个问题有了更具体的理解。代码评审不是一个单独的仪式，它需要和小粒度提交、清晰 Issue、自动化检查、测试用例和讨论记录一起工作。真正进入一个项目时，比较可行的方法不是一上来就改核心逻辑，而是先跑通项目、读文档和历史提交，再从局部功能或小问题开始。结对项目中，我们围绕策略函数反复确认边界情况；团队项目中，Issue 和阶段总结也起到了类似的作用，把“谁改了什么、为什么改”留下来。这样新人至少有路径可循，而不是只靠猜。

第三个问题是团队模式。大型软件公司到底应该采用固定团队，还是根据功能临时组织团队？现在我觉得没有绝对答案。固定团队的好处是能积累领域知识和协作习惯，临时的功能小组则适合集中解决某个阶段的目标。我们的团队项目里，大家有相对稳定的分工，比如开发、美术、测试、发布等，但到 Alpha、Beta 的具体推进时，又会根据问题临时调整协作方式。这个经历让我觉得比较好的状态是“稳定分工加上阶段性协作”，既不能每次都从零磨合，也不能因为分工太固定而没人补位。

第四个问题是项目延期会造成什么损失。以前我把延期更多理解成“晚一点交付”，但实际项目里，延期带来的问题会往外扩散。它会影响测试时间、队友安排、用户反馈窗口，也会让后续集成和发布更紧张。我们团队项目 Beta 阶段有不少 Issue 集中在后期关闭，虽然最后成果完成了，但这种节奏也说明如果前期估计不足，后面就会把压力堆到测试和发布阶段。软件项目里的时间成本不只是日历上的几天，还包括返工、沟通、士气和机会成本。

第五个问题是职业伦理。当时我问的是，程序员为了保护自己的利益，是否可以留下后门或利用技术手段做一些不诚实的事情。现在我的答案更明确：不应该。技术能力越强，越不应该把它用在破坏信任的地方。后门不仅伤害用户，也会伤害团队和职业本身。如果个人权益受到损害，合理的方式应该是保留证据、明确合同和职责边界、通过沟通或法律途径解决，而不是用技术欺骗去反制。团队项目让我更能感受到这一点：一个软件能跑起来，是很多人互相信任、互相接住工作的结果，一旦有人故意破坏，这种协作基础就不存在了。

原来的问题现在基本都有了更具体的答案，但也不是说完全想明白了。比如“流程应该轻到什么程度”这个问题，我还是觉得和团队规模、项目风险、成员经验有关。课程项目中的流程已经足够支撑一个学期的开发，但如果放到更大的真实项目里，可能还需要更严格的代码评审、自动化测试和发布管理。新的问题则是：当 AI 工具逐渐参与代码生成、测试和文档整理时，软件工程中的责任边界应该怎么划分？AI 可以提高效率，但需求理解、架构选择和最终质量仍然需要人负责，这一点以后还需要在更多项目里继续体会。

二、六个阶段中学到的知识点

需求阶段。 我学到的是，需求不是把想做的功能全部列出来，而是要先分清用户真正要解决的问题、核心场景和优先级。没有优先级的需求列表会让后续设计和开发都变得混乱。做网易云音乐案例分析时，我也发现同一个功能在不同用户眼里价值并不一样，所以需求阶段不能只靠自己的感觉。

设计阶段。 设计不是只画界面或结构图，而是提前处理模块边界和交互方式。设计阶段想清楚一部分问题，后面实现时就少很多临时决定。结对项目里，我们在实现花见小路 AI 前，需要先理解规则、状态表示和策略接口，否则后面写代码很容易互相对不上。

实现阶段。 写代码时要考虑团队协作，代码能跑只是第一步，命名、接口、目录结构和提交粒度都会影响别人是否能接着维护。团队项目里，分支、Commit Message、PR、Review 和 CI 都会影响实现质量。实现不是把功能写完，还包括让代码能被别人理解、检查和合入。

测试阶段。 测试要覆盖正常路径，也要覆盖边界情况和用户实际可能的误操作。花见小路项目里，平局、11 分获胜、4 个艺伎标记获胜、最高档位比较、隐藏信息恢复等情况都需要专门考虑。团队项目里，测试也不只是检查程序有没有崩溃，还要看引导是否清楚、数值体验是否稳定、操作反馈是否明显。

发布阶段。 发布不是把最终版本打包出来就结束，还要说明版本内容、已知问题和使用方式，让别人可以真正复现和体验成果。团队项目从 Alpha 到 Beta 都有发布博客和展示博客，这让我意识到，能被别人顺利运行和理解，也是软件成果的一部分。

维护阶段。 维护依赖前面积累的记录。Issue、提交历史、测试结果和阶段总结都能帮助团队判断问题来源，而不是靠回忆。Beta 阶段关闭 Issue 的过程让我感受到，维护不是项目结束后的附加工作，而是从需求、实现和测试阶段就已经开始了。

三、结合项目经历的理解

个人作业更多是在建立软件工程的基本意识。I.1 的阅读与提问让我把自己对课程、团队、延期、代码评审和职业伦理的疑惑写出来；I.2 的软件案例分析则让我第一次比较认真地从用户角度分析一个具体软件。我当时分析的是网易云音乐，除了功能体验，也关注了后台自启动、年度报告数据异常、多设备同步等问题。这个过程让我意识到，软件工程关心的不只是代码本身，还包括软件如何被使用、如何被评价、如何持续改进。

结对项目让我感受到协作开发和个人编程很不一样。我们做的是花见小路 AI，一开始我对 WebAssembly 和花见小路规则都不熟，需要先补规则、再理解项目框架，最后实现策略函数。这个过程中我学到比较多的是边界情况和接口约定：同一个策略判断，如果没有把分数、标记、隐藏信息和回合状态说清楚，两个人很容易写出理解不一致的代码。相比一个人闷头写，结对编程更考验表达和互相理解，也更容易在讨论中发现盲区。

团队项目是这学期最接近真实软件工程实践的部分。我们小组的博客园主页是 FruitInc，项目 HexaVigil 是一个基于 Godot 的策略塔防/生存 Roguelite 游戏。从 团队成员介绍 到选题和需求分析、功能规格说明、技术规格说明，再到 Alpha、Beta 两个阶段的计划、测试、发布、展示和总结，整个过程几乎把软件工程课上的流程走了一遍。

整个学期下来，我对软件工程的理解从“管理代码的规则”变成了“管理不确定性的办法”。需求会变，成员状态会变，代码会有 Bug，资源会缺，发布会出问题，用户也可能不按我们预想的方式使用软件。软件工程不能消除这些不确定性，但能让它们更早暴露、更容易讨论、更方便处理。

如果只从结果看，我们确实做出了一个可展示、可发布的项目；但更重要的是，我看到一个项目是怎样从一句想法变成需求、文档、Issue、代码、测试、发布包和总结报告的。这个过程没有想象中那么顺滑，也没有教材里那么标准，但正是这种不完全标准的实践，让我对软件工程有了比较真实的认识。

四、最后的总结

这门课给我的最大收获，不是学会某一个具体工具，而是对“项目”这个词有了更具体的理解。个人项目主要考验自己能不能想清楚并写出来；结对项目考验两个人能不能在短时间里对齐理解；团队项目则考验一群人能不能持续同步、拆分任务、处理变化，并最终交付一个能运行的东西。

我现在仍然不敢说自己已经会做软件工程了，但至少不会再把它理解成单纯的文档、流程或口号。它更像是一种工程习惯：写代码前想清楚需求，写代码时考虑别人怎么接，写完后用测试验证，发布前确认风险，结束后认真复盘。这个习惯不一定每次都能做得很好，但只要项目稍微复杂一点，它就会变得很重要。

以后如果再做类似项目，我希望自己能更早参与需求和验收标准的讨论，也能在测试和发布准备上更主动一些。因为这学期最明显的感受就是：真正影响项目质量的，往往不是最后一天多写了多少代码，而是更早之前有没有把问题拆清楚、有没有留下足够的检查点、有没有让团队知道现在最重要的风险是什么。