构建之法阅读笔记02

阅读内容
《构建之法》第二版 第4章～第6章（两人合作、团队和流程、敏捷流程）

核心概念摘要
两人合作的核心不是"分工写不同的文件然后拼在一起"，而是通过代码复审（Code Review）、结对编程、代码规范约定等手段形成共同的质量标准。代码复审不是领导对下属的检查，而是开发者之间的知识传递和质量把关过程——每一行代码在被合入主分支之前，至少要有第二个人完整读过并理解它。

团队协作中，团队规模、沟通成本和流程选择三者强相关。书中用"人月神话"的经典结论指出：当项目延期时，单纯加人不仅不能缩短时间，反而会因为沟通链路指数级增长而进一步拖延。敏捷不是"不写文档、疯狂堆功能"，而是用短迭代、持续交付和频繁反馈来降低需求变更的损失——承认需求一定会变，所以把验证周期缩到最短。

个人感受
1、我过去是怎么做的

在小组课程项目中，我们所谓的"合作"就是：组长把需求拆成几个模块，每个人认领一个，各自在本地写，最后约定一个时间"合代码"。合代码的那个晚上往往是灾难——A 同学的函数签名和 B 同学传的参数对不上，C 同学改了共享数据结构但没通知任何人，D 同学的代码注释全是本地语言风格别人完全看不懂。整个过程没有人做过一次真正的代码复审，更没有人敢于指出别人的代码问题，因为觉得"大家都是同学，提意见伤感情"。最后通宵改 bug，勉强交差。

2、结合书中所讲，说明为什么这样不好

书中把这种模式称为"各自为战 + 最后集成"的反模式。问题在于：

缺乏持续集成意味着所有集成冲突被拖延到最后一刻才暴露，修复成本指数级上升。一个隐性冲突如果在产生的当天发现，改动可能只涉及 10 行代码；拖延三周后再发现，可能涉及整个模块的返工。
没有代码复审等于放弃了一种性价比最高的缺陷发现手段。书中引用数据说明，设计审查能发现约 55% 的缺陷，而代码审查能额外发现约 20%——这些缺陷如果靠测试发现，成本要高得多。更重要的是，复审过程本身就是知识传递：被复审的人学到更好的写法，复审的人也通过阅读别人的代码拓宽视野。
避免冲突的文化导致代码质量螺旋下降。不敢提意见，实际上是在纵容坏味道积累。一次不提，下一次对方还会那样写，最终代码仓库变成没人愿意碰的"雷区"。
3、解决办法

在后续团队项目中，我计划推行以下规则：

每日集成 + 合入门槛：每个成员每天至少 push 一次代码到开发分支，连续两天不 push 要在站会上解释。合并 pull request 必须满足三个条件——所有单元测试通过、至少一位团队成员完成代码复审并点通过、无未解决的评论线程。
复审清单制度：在 GitHub PR 模板中内置一份复审 checklist——命名规范、边界情况处理、是否有重复代码可以抽取、是否有必要的注释、是否引入了硬编码常量。复审者逐项打勾，不允许空泛的"LGTM"就过。
对事不对人的复审文化：团队约定复审评论的格式——每条意见都以"这段代码……"而非"你……"开头。提意见是帮对方变强，不是找茬。如果哪次复审一条意见都没有，反而说明复习不够认真，应当打回重审。