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

项目	内容
这个作业属于哪个课程	北航 2026 年春季软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	在实际项目中运用上先进的软件工程管理方法，提高开发效率和项目质量
这个作业在哪个具体方面帮助我实现目标	回顾整个学期的学习历程，对知识和经验进行系统性梳理

链接到以前提问题的博客

[I.1] 个人作业：阅读和提问

请尝试对自己曾经提出的问题进行解答

问题 1：兜底异常，还是 100% 单元覆盖率？

如果单元测试确实无法覆盖兜底的异常，在我的实践中，我会把这个错误处理去掉，而不是一味防御性编程。这样来好处是，能更好发现具体的错误类型，针对不同的错误可以有特殊的逻辑；采用 catch(e : Exception) 反而可能导致错误被隐藏，影响后续逻辑，造成更大的错误。

问题 2：高级程序员与原文中“C 类医生”有可比性？

真正的程序员不应该是精湛于做某一种手术、有无数成功案例的医生，而更像是在急诊科有着丰富经验的主任医师。急诊科里送来的病人没有完全相同的病例情况，有人是车祸，有人是中毒，有人是心梗，五花八门。但是有丰富经验的主任医师能够根据病人的情况采用特殊的救疗方案。因此他们绝对不只是C类医生，他们每一次手术都人命关天，更别提“一边开刀，一边聊天”。

现实中，也确实有C类医生似的程序员。运维工程师需要每天重复执行服务器重启、Nginx 配置更新、日志切割。这些都是闭着眼就能敲完的命令，确实可以边操作边听相声。这类“C类程序员”确实存在，但他们通常处于技术鄙视链的底端，且正被低代码平台和 AI 迅速取代。

问题 3：结队编程的“IO 争抢”是否合理？AI 时代是否还需要结对编程？

现代敏捷团队更加采用双屏、双主机的模式，或者采用远程结对工具，绝不是“使用同一个键盘、同一个鼠标一起工作”，后者导致严重的人机 IO 争抢，降低编程效率。试想如果驾驶员正在第 1000 行写代码，而领航员需要到第 300 行查看定义，那么代码视图的切换是有巨大成本的，必然导致一方的工作中断。远程结对工具通常支持多光标、独立滚动、多缓冲区，领航员完全可以在另一台电脑查阅定义。在这种现代模式下，“同一套键盘鼠标”完全被抛弃了。

AI 领航员拥有比人机交互更高的 IO，能够快速查找定义、查阅资料，给代码编写者提供及时而准确的提示。但是目前的 AI 水平很难从宏观上审视整个系统架构是否合理，没有特定领域的专用编程经验，与 AI 合作写代码，如果没有额外的架构设计与把关，很容易形成屎山代码。同时人类领航员最可贵的地方在于“固执”，人会有自己的喜好、自己的思想，并不会 AI 那样一味顺从代码编写者的设计，而是思考并主动提出更优的方案，后者才能显著提升代码的质量，达到结队编程的效果。在我的团队作业中，就是因为与 AI 合作过多、人工审阅过少，导致代码质量的降低，对后续开发和维护造成了显著的影响。

问题 4: 从软件估算公式推出初次项目永不成功？

Y = X ± X ÷ N, 该公式不是严格的数学公式或科学定律，也不是实验出来的经验公式，而是某种观念的数学表达，所以不在乎严谨性，也并不严谨。细节上来讲，把 N 定义成“做过类似开发工作的次数”时，已经为漏洞埋下了伏笔。“类似”本身就是主观的、可延展的。只要搜索能力、阅读文档能力、逻辑推理能力存在，一个人的 N 永远不会是 0。同时它把人的能力视为静态的，第一次做就是绝望，第二次才能成功。但真实的人是在过程中不断进化的。程序员可以边做边学，做完了后还增长了能力。

这条公式最有价值的意义，在于对决策层泼冷水，如果某些功能是第一次做，就需要谨慎工期计算，甚至要做好失败的打算。在我的团队作业，项目的核心亮点是通用规则引擎和低代码平台，而这二者的 N 对于我们来说都是 0, 因此项目工期的计算就显得过于乐观，实际上我们完成相应功能需要更长时间。

问题 5：“事后诸葛亮”的副作用记录？

“我们要把这些副作用明明白白地写出来。”我认为这确实是原书的 bug，首先这句话准确来说应该是“我们要把‘已知的’副作用明明白白地写出来。”而原书举了产品导致“未知”副作用的例子（LED 无法融化雪是未知的系统性副作用），用了一个只有事后才能知道的副作用，来教育读者“事先要写清楚”，这在逻辑上是不自洽的。

如果把副作用事无大小全部列举出来，Spec会变成一本永远读不完的百科全书，失去指导意义。通过询问 AI，AI 告诉我：在实际工程中，通常采用“三层过滤法”来决定记录深度：

层级	定义	记录要求	LED示例
L1 - 直接影响业务逻辑	会改变用户可感知的行为或系统核心功能	必须记录，且写进测试用例	如果LED亮度降低导致交通灯可视距离缩短，则必须记录
L2 - 影响运维/环境适配	不影响功能，但影响部署、维护、成本	建议记录，列入运维手册	LED发热减少，这可能导致积雪不化
L3 - 理论上存在但概率极低	在极端条件下才可能触发的关联	简略记录，或标记为“待观察”	LED的色温变化是否影响驾驶员疲劳，目前无证据，留待后续数据验证

新产生的问题

AI 时代，协作者使用 AI 完成代码编写是常见的事情，但是由于 AI 的上下文等限制导致 AI 对我所设计的 DDD 架构不太理解，导致后续的提交不按照架构分层，甚至把我之前按照架构写好的内容重写回单层无架构版本（我遇到的情况是，AI 把业务逻辑、查表、输出全部放在接口处处理，导致架构的解体）。这时我们应该如何去与协作者合作？如何让对方的 AI 按照架构编写代码来保持代码的高质量？

另外，AI 为了通过硬性约束往往会走捷径，比如为了通过编译期检查，就把编译期检查改成运行时检查（我遇到的问题是，AI 把我写的 sqlx::query! 全部改成 sqlx::query，前者会编译期在线检查字段名、类型是否匹配，并减少模板代码，而后者不做检查，留到运行时报错）；为了通过测试样例，就把测试样例直接删除；为了运行时数据库不报错，就在业务代码中写上 CREATE IF NOT EXISTS 的建表语句（理应让开发人员执行 SQL）。一般这些问题只能通过人工 review 的方式解决，但是项目工期较赶、AI 写的代码过多的情况下，审阅 AI 代码的成本往往更大。如何让 AI 直面约束，高质量地解决问题？

在项目的需求、设计、实现、测试、发布、维护阶段中学到的知识点

我在项目中负责了一部分需求设计和开发实现，暂时没有参与测试、发布、维护。

需求上，我学到了 NABCD 分析法，先深挖用户痛点，把模糊的用户诉求转化为清晰、可验证的目标，同时避免盲听用户诉求。另外，学到了对比竞品使差异化优势更加显著。

设计上，我认为一个良好的设计是产品成功的关键，设计比开发更重要。架构设计上，我学到了领域驱动设计（DDD） 和干净架构；项目设计上，学到了 DSL 设计与 WebSocket 通信设置。

实现上，学会了github工作流，包括分支管理、pull request、CI 自动化集成等规范操作。

结对编程、团队项目的经历与心得

在结队项目中，我与算法非常强的 cwz 结队完成了《花间小路》的实现。我熟悉 rust 语法和 wasm 工具，他熟悉高效算法的实现。通过两个人优势互补，编程效率提高了，程序性能也更好了。

在团队项目中，我负责后端开发，主要问题是与前端的对齐，我提供的 api 操作与前端认为的 api 操作有区别，就算我已经写了完整的 api 文档。我认为项目中必须设立一个中端的职位来统筹设计，或者将前端后端拉过来一起设计、达成共识。另外，与过多得使用 AI 的协作者合作也是困扰我的最大问题，这一点已经在“新产生的问题”中提出。