[I.3] 个人作业：结课总结
一、前言
学期初，我们通过快速阅读软件工程相关材料，提出了自己对软件工程的疑问。当时我写下的阅读提问博客是：
当时我主要提出了五个问题：
- PM 是否应当具备一定的技术能力？
- AI 时代下软件工程师的技能点是否已经变化？
- 敏捷开发和软件行业是否完全适配？
- AI 时代下，我们应该如何在快速迭代和可拓展性中取舍？
- 当软件工程越来越多地走进传统行业，传统的发布方式是否应当更新？
一个学期过去后，我们完成了个人项目、结对编程、两个阶段的团队项目，也经历了转会环节，再回头看这些问题，我发现自己对软件工程的理解已经从书本概念逐渐变成了项目实践中的具体体会。
二、对最初五个问题的回顾与解答
1. PM 是否应当具备一定的技术能力？
我现在的看法是：PM 不一定需要像开发者一样深入写代码，但应当具备基本的技术理解能力和技术沟通能力。
学期初我认为，如果 PM 具备一定开发能力，可能可以减少需求理解偏差和时间评估失误。但经过团队项目后，我发现问题并不是简单地让 PM “会写代码”就能解决。即使是开发者本人，也经常会低估某个功能的复杂度。一个看起来简单的需求，背后可能涉及接口调整、数据结构变化、测试适配和已有逻辑修改。
因此，我现在更倾向于认为，PM 最重要的不是亲自参与编码，而是能够理解技术风险，尊重开发成员的评估，并在需求、进度和质量之间进行协调。真正能减少矛盾的，不是把所有能力都集中到 PM 一个人身上，而是建立更合理的协作机制，让需求决策、技术评估和项目规划能够由团队共同完成。
这个认识主要来自团队项目中的任务分配和沟通实践。只有真正经历过需求讨论、工期估计和进度调整，才会理解 PM 和开发之间的矛盾并不是单纯的技术问题，而是协作机制问题。
2. AI 时代下软件工程师的技能点是否已经变化？
我认为软件工程师的技能点确实发生了变化，但核心能力并没有消失，而是变得更加偏向综合判断。
AI 工具现在已经可以帮助开发者生成代码、解释报错、补充测试、查找资料，甚至快速上手陌生技术栈。这让我重新思考：过去我们花很多时间学习某种语言或框架的细节，未来这些低层次问题是否会变得不那么重要？
经过一学期实践后，我的理解是：AI 降低了写代码和学习新技术的门槛，但没有降低工程判断的重要性。AI 可以生成一段代码，但这段代码是否符合当前项目结构，是否考虑了边界情况，是否会影响后续维护，仍然需要人来判断。如果没有扎实的基础知识和项目理解能力，开发者甚至无法判断 AI 给出的答案是否可靠。
所以，AI 时代的软件工程师需要的不只是“会写代码”，还包括准确描述问题、拆解任务、审查 AI 输出、理解系统结构和把控软件质量的能力。语言和框架仍然要学，但它们更像是实现想法的工具。真正重要的是计算机基础、学习能力、系统设计能力和工程实践能力。
3. 敏捷开发和软件行业是否完全适配？
我现在认为，敏捷开发适合软件行业中的很多场景，但不能认为它和所有软件项目都完全适配。
学期初我对敏捷开发有一些怀疑。敏捷强调短周期迭代、持续反馈和每日立会，但在现实开发中，需求变更频繁、任务延期、测试覆盖不足等问题依然存在。甚至每日立会有时可能会流于形式，变成一种机械汇报。
经过团队项目后，我对敏捷的理解更具体了。敏捷的价值不在于“每天开会”这个形式，而在于让团队尽早暴露问题、及时调整计划、避免最后才发现方向错误。在课程项目这种需求不完全明确、时间有限、团队成员经验不同的情况下，小步迭代确实比一开始制定一个看似完美的计划更现实。
但敏捷也不是万能的。如果团队没有真正沟通，只是形式上开会；如果需求随意变化，却没有优先级管理；如果只强调快速实现，却忽略测试和文档，那么敏捷反而会变成混乱的借口。
因此，我现在的答案是：敏捷开发和软件行业有很高的适配度，但并不是完全适配所有场景。对于不确定性强、需要快速反馈的项目，敏捷很有价值；但对于医疗、汽车、工业控制等高风险软件，仅靠敏捷是不够的，还需要更严格的设计、测试、审查和发布流程。
4. AI 时代下，我们应该如何在快速迭代和可拓展性中取舍？
学期初我提出这个问题，是因为书中提到“过早泛化”是一种常见误区。但我又想到，在 AI 提高开发效率的背景下，适度提前设计是否会变得更有意义。
经过实践后，我认为快速迭代和可拓展性不是绝对对立的，关键在于判断哪些地方值得提前设计，哪些地方应该保持简单。
在项目中，有些功能如果一开始完全不考虑结构，后期修改会非常痛苦。比如核心数据结构、模块边界、接口约定，这些内容一旦被大量代码依赖，后续重构成本就会很高。但另一方面，如果对一个还不确定的功能过早抽象，也可能让代码变得复杂难懂，甚至浪费开发时间。
所以我现在更认可“适度设计”的思路。对于核心功能、稳定需求和多人协作接口，应该提前考虑可扩展性；对于实验性功能或不确定需求，可以先用简单方案快速验证。AI 可以让写代码更快，但不能替代我们判断架构是否合理。
也就是说，AI 时代下快速迭代仍然重要，但可拓展性也会变得更重要。因为当代码生成本身变快后，真正影响项目长期发展的，往往不是某一段代码写得慢，而是整体结构是否清晰、是否容易修改和维护。
5. 当软件工程越来越多地走进传统行业，传统的发布方式是否应当更新？
我现在认为，传统发布方式确实应当更新，尤其是在高风险行业中，不能继续依赖“出了问题再打补丁”的思路。
在互联网软件中，alpha、beta、RC 版本以及后续补丁更新是很常见的发布方式。很多时候，软件出 bug 后可以通过快速修复和版本更新来解决，用户也相对接受这种模式。
但当软件进入智能汽车、医疗设备、工业控制等传统行业后，情况完全不同。一个小 bug 可能不只是影响用户体验，而是可能造成现实世界中的严重后果。这样的软件不能只依赖企业自觉测试，也不能简单采用“先发布，后修复”的方式。
通过课程项目的发布过程，我也体会到“能在自己电脑上运行”和“真正可发布”是两回事。发布不仅包括代码完成，还包括测试、文档、环境配置、版本管理、异常处理和用户使用说明。即使是课程项目，如果没有这些内容，别人接手或使用都会有困难。
因此我认为，软件工程进入传统行业后，发布流程必须更加严格。不同风险等级的软件应该有不同的发布标准。普通互联网产品可以快速迭代，而高风险软件则需要更完善的测试标准、代码审查、发布审批、回滚机制甚至行业监管。
三、仍然没有完全弄明白的问题
虽然这五个问题现在都有了更清晰的理解，但仍然有一些地方我还没有完全弄明白。
首先，PM 到底需要懂技术到什么程度，我还没有确定答案。不同项目对 PM 的技术要求不同，业务型产品和底层技术型产品显然不能用同一套标准衡量。
其次，AI 对软件工程师能力结构的影响仍在快速变化。现在 AI 主要是辅助开发，但未来它是否会进一步改变团队分工、招聘标准和软件工程教育，我还需要继续观察。
另外，敏捷开发在学生团队中如何真正落地，我仍然觉得不容易。流程太少容易混乱，流程太多又会占用开发时间。如何找到适合团队规模和项目周期的平衡点，是我还没有完全解决的问题。
四、新产生的问题
经过一个学期的项目实践，我又产生了一些新的问题：
- 当 AI 能够生成大量代码后，软件工程课程是否应该更重视代码审查、系统设计和需求分析？
- 学生团队应该如何判断一个需求是必须完成，还是应该推迟甚至放弃？
- 技术债是否可以被量化？如果不能量化，团队应该如何判断什么时候偿还？
- 对于课程项目这种周期短、人员流动大的项目，怎样的文档才是足够有效的？
五、六个阶段中的知识点总结
1. 需求阶段：需求澄清
需求阶段我学到的知识点是需求澄清。一个需求不能只写“要做什么”，还要明确用户是谁、使用场景是什么、做到什么程度算完成。如果需求没有澄清，后面的设计和实现很容易出现偏差。
2. 设计阶段：模块化设计
设计阶段我学到的是模块化设计。团队项目不是一个人写完所有代码，模块边界越清晰，成员之间的协作成本就越低。好的模块划分也能让后续修改更加集中，减少牵一发动全身的问题。
3. 实现阶段：版本控制
实现阶段我对 Git 协作有了更深体会。版本控制不只是保存代码，还包括分支管理、提交记录、冲突解决和代码合并。团队项目中，如果没有良好的版本控制习惯，协作会变得非常困难。
4. 测试阶段：回归测试
测试阶段我学到的是回归测试。项目不断迭代时，新功能可能破坏旧功能。测试不能只测刚完成的部分，还要检查已有核心功能是否仍然正常，这样才能减少后期集中爆发的问题。
5. 发布阶段：可交付性
发布阶段我理解了可交付性。软件不是在自己电脑上能跑就算完成，还要让别人能够安装、运行、理解和使用。环境配置、依赖说明、版本记录和使用文档都属于发布的一部分。
6. 维护阶段：技术债
维护阶段我学到的是技术债。为了赶进度写出的临时代码，短期内可能解决问题，但长期会增加修改和理解成本。技术债并不一定完全不能有，但团队必须意识到它的存在，并在合适的时候处理。
六、结合项目经历的个人心得
个人项目让我体会到，独立完成一个程序不仅需要写代码，还需要自己理解需求、拆解问题、处理边界情况和调试错误。它让我第一次比较完整地经历了从需求到实现的过程，也让我意识到基础能力的重要性。
结对编程让我感受到沟通本身就是开发的一部分。两个人一起完成任务时，思路不同是正常的。有时候讨论会降低短期速度，但也能帮助发现自己忽略的问题。相比一个人写代码，结对编程更需要表达清楚自己的想法，也需要认真理解对方的思路。
团队项目则让我真正理解了软件工程为什么强调流程和协作。多人开发时，问题不再只是“代码怎么写”，还包括需求怎么定、任务怎么拆、接口怎么约定、代码怎么合并、测试怎么安排、进度怎么同步。一个人能力再强，也很难替代整个团队的协作机制。
转会环节让我对项目维护和交接有了更深体会。如果一个项目只有原成员才能理解，那么它的可维护性就是有问题的。清晰的代码结构、必要的文档、规范的提交记录和明确的任务说明，都会影响后来者能否顺利接手。
经过这个学期，我对“做中学”有了更深的理解。软件工程中的很多知识点，如果只看书，会觉得抽象甚至有些理所当然；但经历过需求变化、代码冲突、功能延期、bug 修复和团队协作之后，就会明白这些方法并不是形式，而是为了让团队在复杂情况下仍然能够交付可用的软件。
七、总结
回顾学期初提出的五个问题，我发现自己对软件工程的理解已经发生了变化。最初我更多是在讨论 PM、AI、敏捷、架构和发布这些概念本身；现在我更关注它们在真实项目中如何落地。
我现在认为，软件工程不是简单地把代码写出来，而是在需求、设计、实现、测试、发布和维护的全过程中，用合适的方法降低不确定性，提高协作效率，并保证软件质量。
PM 是否懂技术、AI 是否改变工程师能力、敏捷是否适合软件行业、快速迭代和可拓展性如何取舍、传统发布方式是否需要更新，这些问题都没有绝对答案。它们都需要结合具体团队、具体项目和具体风险来判断。
这门课最大的收获，是让我认识到软件开发不是孤立的个人编码活动，而是一项需要沟通、判断、协作和持续改进的工程实践。相比学期初，我对软件工程的认识不再只停留在书本上，而是开始理解它为什么会在真实项目中发挥作用。
浙公网安备 33010602011771号