04《构建之法》阅读笔记

从"码农"到工程师：《构建之法》给我的当头一棒

翻开《构建之法》前，我一直自诩为"资深程序员"。直到这本书像一面镜子，照出了我工作中那些自以为是的坏习惯——那些让我永远停留在"码农"阶段而不自知的陷阱。

"能跑就行"的代码之殇

"这个功能先实现，后面有时间再优化。"这句话简直是我的口头禅。记得上个月做用户登录模块时，我花了2小时快速实现了一个基于session的方案，数据库查询直接写在Controller层，密码甚至用明文暂存。当同事提醒时，我还振振有词："现在重点是赶进度，等上线后再重构。"

邹欣老师在书中一针见血地指出："代码质量不是可以后期添加的调料，而是从一开始就必须构建的基础。"那些"临时"方案往往成为系统永久的组成部分，而后期修改的成本是前期设计的10倍不止。我的做法不仅增加了技术债务，更给系统埋下了安全隐患。

解决办法：现在我强迫自己在写每行代码前问三个问题：(1)这段代码半年后别人能看懂吗？(2)如果需求变化，修改成本有多高？(3)出现异常时会发生什么？这个小习惯让我的代码质量有了肉眼可见的提升。

文档：最熟悉的陌生人

"代码即文档"曾是我的信仰。去年接手一个老项目时，我对着5万行没有注释的代码骂了前任开发者三天三夜。但转身在新项目中，我自己写的README.md只有两行："# XX系统 \n 使用SpringBoot"。直到看到书中"文档是写给六个月后的自己看的情书"这句话时，我才恍然大悟。

邹欣用"破窗理论"解释文档的重要性——第一个缺失的文档就像第一扇破窗，会导致整个项目质量迅速滑坡。没有文档的代码就像没有地图的迷宫，每次修改都在黑暗中摸索。

解决办法：我现在把写文档当作编码的一部分，采用"三明治工作法"：开始功能前写设计概要，编码时用注释记录关键决策，完成后补充使用示例。使用Swagger等工具让API文档自动生成，省时又规范。

当单元测试成为"奢侈品"

"测试？等开发完再说吧。"这是我见过最普遍的现象。团队里小王每次提交代码都自信满满："我手动测试过了，没问题！"结果每次上线后半夜都会被报警短信吵醒。我以前觉得写单元测试是"浪费时间"，直到书中那个"调试时间与测试覆盖率的关系图"让我震惊——高测试覆盖率反而总耗时更少！

《构建之法》中提到的"测试驱动开发不是可选项，而是工程实践的底线"点醒了我。没有自动化测试的代码就像没有安全网的走钢丝，每次修改都是赌博。

解决办法：我现在强制自己使用"红-绿-重构"循环：先写失败测试(红)，再实现刚好通过的代码(绿)，最后优化结构(重构)。搭配Jenkins做持续集成，测试覆盖率不到80%的代码不允许合并。虽然初期耗时增加，但再也不用半夜爬起来修bug了。

个人感受：从认知颠覆到行为革命

现在的我开始实践书中的"工程师思维"

这些改变让我的代码开始有了"工程味"，而不仅仅是"能跑"。感谢《构建之法》这记当头棒喝，它让我明白：好的程序员写出能工作的代码，而真正的工程师构建可持续演进的系统。这条路我才刚刚起步，但至少，我已经不会在起点就挖坑给自己跳了。