《构建之法》阅读笔记

这本书对我的帮助挺大，之前总是“面向功能”去编程，觉得软件达到自己心理预期的功能了就可以结束了，读完这本书，结合老师上课的内容，才开始真正从用户的角度去理解软件的构建。希望后面可以在实战中慢慢消化内容。

按照课程的要求，写了几个问题or笔记，不正确的地方请老师指正。

第二章 个人技术和流程

L202-L210测试案例是不是写错了？

飞行员正在输入的时候应该返回true而非false。要实现虚假的100%测试，这里的测试用例应该是：false, false, false，即飞机不在着陆，且飞行员没有手动输入控制指令，系统没有检测到严重故障，这时候返回false是没问题的。

第三章 软件工程师的成长

这章看完之后，对ai辅助编程，也就是所谓“氛围编程”有一些心得。

我在使用ai进行陌生领域的开发（我原先熟悉的是c/c++做计算机视觉和三维重建方面的开发，对python、java等使用并不熟悉，因此在全栈开发的过程中几乎一窍不通）时有这样的感受：
1. 如果你只是想做一个个人爱好级别的项目，ai完全有能力生成一个小型规模的软件，并且经过一周左右的调试（直接把问题反馈给ai修改）后各方面实现我们的需求。
2. 如果在项目已经完成后，想再对该项目做大量修改，比如采用自己个人喜欢的布局、加入大量完善的单元测试、细节功能上的打磨等等，ai就几乎无能为力了。一方面是上下文token的限制，ai目前已经可以生成大规模的代码，但是却不能记住自己写的所有代码。代码达到一定量时再去修改（这里还是指的是直接让cursor、claude code等去修改，而不是明确指出我需要修改某个文件中的哪个模块），会消耗大量的时间去查询和理解相关代码。
3. 因此，尽管现在很多人在提“氛围编程”，强调只要工程师有明确的结构、框架，哪怕不熟悉语法也可以做任何项目，目前而言这是不太现实的。对现代工程师最起码的标准是，你需要熟练基本语法、常见的模块写法，能完全看懂、理解ai在写什么（也就是把基本语法作为自己认知区域的舒适区，而不是一窍不通就直接拿ai去开发软件），然后才能开发出一个工业级的软件。

第六章 敏捷流程

书中提到了BMad方法，将AI时代的敏捷流程重新总结为四个阶段：

Benchmark, Model, Apply, Deploy

我想到按照前面第二章所述的TDD方法，第二阶段和第三阶段是否可以互换？

在设计单元测试的时候就把接口、前后端的框架搭好，然后再去做实验做建模。

第十一章 软件设计与实现

看到第11.6节的“脚手架”比较印象深刻：软件工程的质量不仅取决于代码本身，更取决于围绕代码的整套工具链、流程和基础设施。

但是，正如老师在书中所说，代表着一种全新的、颠覆性的元方法的ai代码生成的出现，以及随着Claude Code, CodeX这些工具越来越成熟，脚手架的建设能否跟上这个速度？

一方面是测试覆盖率的问题，正如老师在书中所说，人非圣贤、总会有这样那样的问题，ai更是如此；当未来ai生成的代码量激增，而测试脚手架跟不上时，我们是否会面临一个功能爆炸但是质量奔溃的困境？

另一方面，技术债务的问题。传统的技术债务主要来自”快速且粗糙的实现“，而在ai时代，技术债务可能来自快速生成但缺乏整体架构思考的大量代码，这种ai生成的技术债务是否更难识别和偿还？

等等这些问题。

我们是否需要一个ai时代的脚手架清单？什么样的工具、流程、规范能够确保ai辅助开发在提升效率的同时，不会以牺牲长期质量为代价？软件团队应该如何平衡快速迭代和稳健工程？