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

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR/homework/15687
我在这个课程的目标是	系统性的学习软件工程的知识，逐步成为一个成熟的软件开发者
这个作业在哪个具体方面帮助我实现目标	总结软件工程课程中我的问题，明确未来奋斗目标

一、问题回答

链接到以前提问题的博客：https://www.cnblogs.com/cwz2024/p/19694040

如何区分 re-work 是“有价值的探索”还是“低水平的重复劳动”？

在实际管理中，可以从三个维度进行操作性区分：

1. 知识增量：让工程师在每次 Re-work 后提交一份简短的“修改日志”，重点说明“我这次修改发现了什么之前不知道的东西？”，例如：发现了一个隐藏的性能瓶颈，或证明方案A在并发下不可行。如果日志空洞，仅为调整代码格式或循环逻辑，则倾向低水平劳动；如果日志带来了对系统或业务的新认知，则属于有价值的探索。
2. 修改半径：有价值的探索往往牵涉架构级或接口级的调整（影响范围大，但次数少）；低水平重复往往集中在函数内部实现的反复摇摆（影响范围小，但次数多）。管理者可以关注 Re-work 是否改变了模块间的契约。
3. 后悔测试：在修改完成后，问工程师：“如果回到最初，基于现在的认知，你还会选择走这条路吗？”若答案是“会，因为不试错不知道边界”，则是良性探索；若答案是“不会，纯粹是因为我当时没看文档/没写测试”，则是低水平重复。

从“Master/Slave”方案的失败到“Program Manager”模式的成功，这种演变是否真正解决了软件团队沟通的复杂度问题？

PM模式没有“解决”沟通复杂度，而是将O(n²)的“全连接无结构噪音”转化为了O(n)的“结构化瓶颈”，这是一种在工程上可接受的“复杂度转移”，而非消失。PM作为瓶颈，虽然负荷重，但瓶颈是可见且可替换的。如果让开发团队全员承担O(n²)沟通，瓶颈是隐形且不可控的。

“赢者通吃”式评分规则是否会过度激化学生之间的竞争，反而削弱团队合作和互帮互助的氛围？

“赢者通吃”针对的是“团队产出”的外部竞争，而非“团队内部”的人际竞争，运用得当反而能倒逼内部协作。让学生在低风险的教学环境中经历一次“极端挫折”，成本远低于在职场中被市场碾压。只要老师配套充足的“重做机会”或“期中补考机制”，“残酷”就能转化为“防御性刻苦”。

在大语言模型日益强大的今天，传统“做中学”的教学方法是否会面临根本性冲击？如何防止学生滥用AI而失去真正的能力锻炼？

AI冲击的是“代码语法层的做”，但强化了“系统架构层和调试层的做”。“做中学”的定义需要从“Write code”升级为“Architect solution & Fix AI-generated bugs”。文中，邹欣老师提到了“做中学，有疑问再问专家”，而如今AI可以充当那个“24小时在线的初级陪练”。学生遇到编译错误不必再卡死，可以随时问AI，从而将宝贵的课堂时间腾出来解决更高阶的设计问题。

在敏捷开发日益普及的今天，图形化建模方法（如UML）是否还有其不可替代的价值？

严格的“语法级UML”正在消亡，但“图形化架构抽象思维”是永恒刚需。教UML的本质不是教画图，而是教“视角分离”。UML最伟大的遗产是强迫程序员区分逻辑视图、进程视图、物理视图、开发视图和场景视图。当团队在白板上画微服务调用链、画事件风暴时，实际上就在使用UML的核心思想，只是抛弃了繁琐的基数符号。

二、在课程中产生的新的问题

技术债务究竟是“为了生存必须借的贷款”，还是“慢性自杀的毒药”？

由于开发时间紧张，许多项目，包括软工课程中我的团队项目与结对项目，都或多或少存在为了赶上线而暂时写烂代码的情况。现实生活的项目，大多是抱着“未来再重构”的想法，慢慢堆积起技术债务。但我的困惑在于：现实中的“未来再重构”往往永远不会到来。商业压力是永无止境的，一旦“首次上线”成功，下一个迭代立即压来，导致“利息”，即新功能在老旧的烂代码上开发所额外花费的时间，每天都在复利增长。

三、实践中学习的知识点

• 需求：需求规格需要可验证
• 设计：即使是敏捷开发，一个精心准备的好设计也能为项目带来时间收益
• 实现：版本控制是任何项目完美进行的基石
• 测试：自动化测试脚本可以显著提升项目成果评估的效率
• 发布：部署之前要提前做好对应环境的测试，不能在开发环境调试完后就发布
• 维护：在修复bug并推送之前一定要做好回归测试

四、心得体会

在结对编程中，结对的两人需要在极其有限的时间内，首先学习有关 wasm，web assembly/rust 环境配置等项目必需技术栈，然后调研花见小路的高分攻略，最后将策略写成代码并不断测试并优化。整个过程的节奏还是很紧凑的。

不过唯一有些遗憾的，就是直到课程即将结束的时候，课程组也没有给出一个“标杆”级别的引擎，用来帮助我们评估自己引擎的优劣。

五、总结

本学期的软件工程课程让我跳出单纯的代码编写思维，系统掌握了规范化的软件开发理念与方法，收获颇丰。

课程中，我系统学习了软件生命周期、需求分析、架构设计、迭代开发、软件测试与项目管理等核心内容。课程的结对编程让我了解到一个全新的开发模式，而团队开发让我切实体会到团队协作、版本控制和文档编写在工程开发中的重要性。

后续我将深耕软件工程知识，多参与实战项目，打磨规范化开发能力，补齐设计与测试短板，培养严谨的工程素养，为今后从事软件开发相关工作筑牢基础。