《构建之法》| 第四章两人合作：代码规范不是“表面文章“，AI结对编程怎么“知人善任“

本文适合和同事代码风格打架的开发者、从不做代码复审的团队、想尝试AI结对编程但不知道怎么配合的同学。你将收获代码风格与设计规范的核心要点、代码复审的3种形式与核查清单、结对编程的驾驶员/领航员模型、AI结对编程的知人善任策略、两人合作的5个阶段。写在前面前两章聚焦个人——个人技术、个人成长。从第四章开始视角转向人与人的最小协作单位两个人。为什么是两个人因为合作的最小单位不是团队而是两个人。两个人都合作不好团队协作就是空谈。第四版在这一章新增了4.6 与AI结对编程——知人善任这是前三版没有的也是这一版最让我期待的部分。01 | 代码规范合作的前提是说同一种语言两个人合作写代码第一步不是分工而是统一规范。否则你用Tab我空格、你驼峰命名我下划线合并代码就是灾难。1.1 代码风格规范书中给出的原则只有三个词简明、易读、无二义性。具体规定覆盖了这些维度维度规范要点我的踩坑经历缩进4个空格不用TabTab在不同编辑器显示宽度不同合并后代码跳来跳去行宽限制100字符超长行在小屏幕上要左右滚code review时根本看不全括号复杂条件表达式用括号标明优先级a b || c 谁优先不加括号就是埋雷断行每个{和}独占一行压缩在一行看起来省空间但debug时找不到括号对应关系命名Pascal形式类名/ Camel形式变量一个项目里混用两种风格阅读体验灾难级注释随代码更新误导性注释比没有更糟改了代码忘了改注释同事按旧注释理解直接踩坑1.2 代码设计规范风格规范管的是怎么写设计规范管的是怎么设计函数只做一件事并且要做好goto有助于逻辑清晰时可以用不必视如洪水猛兽错误处理Debug版验证所有参数正式版验证外部传入参数断言用于肯定如此的情况错误处理代码用于可能发生的情况类仅在必要时使用避免过度封装我的实战感悟以前觉得代码规范是表面文章——代码能跑就行规范不规范的有什么关系直到有一次接手离职同事的代码没有注释、命名随意、一个函数500行、Tab和空格混用……我花了三天才理清逻辑而如果他有基本的规范意识可能只需要半天。代码规范不是为了好看而是为了降低协作成本。你自己写的代码自己能看懂但别人呢三个月后的你呢一句话提炼代码规范的本质不是约束自己而是善待他人。你写的每一行代码都是别人或三个月后的自己要读的文档。02 | 代码复审看代码是否在规范框架内正确解决了问题2.1 三种复审形式书中定义了代码复审的三种形式形式谁vs谁特点适用场景自我复审自己vs自己最方便但最不可靠——人对自己总是过于自信日常自查同伴复审复审者vs开发者简便易行最推荐的常规方式日常代码提交团队复审团队vs开发者覆盖率高但效率低全体到场关键代码、不再更新的代码2.2 复审的目的不只是找bug而是6个目标1.找出代码错误编码错误、不符合规范2.发现逻辑错误3.发现算法错误4.发现潜在的错误和回归性错误5.发现可能需要改进的地方6.传授经验教育开发人员第6点经常被忽略。代码复审不只是挑错更是团队知识传递的通道。新人通过看老手的复审意见能快速学到什么是好代码。2.3 复审后做什么书中给出了明确的三步处理1.更正明显的错误——当场改2.记录无法很快更正的错误——建issue跟踪3.把错误记入我常犯的错误表——作为以后自我复审的第一步第3步太精妙了。每个人维护一份常犯错误清单每次写完代码先自查这个清单等于给自己加了一层个性化防护。我的踩坑案例我们团队以前没有代码复审流程每个人写完直接提交。有一次两个同事同时改了同一个配置文件的同一个位置合并后谁都没发现上线后系统直接崩了。如果哪怕有一个人做一次同伴复审这种问题5秒钟就能发现。代码复审不是额外负担而是保险。它花5分钟省5小时。一句话提炼代码复审不是审判而是互助。它帮你抓bug、传经验、建规范——一箭三雕。03 | 结对编程两个人一台电脑3.1 两个角色结对编程的核心是两个角色的分工角色职责类比驾驶员Driver控制键盘写代码专注实现细节开车的人领航员Navigator审视全局提醒方向发现潜在问题副驾驶看导航关键点两个角色平等互补不是主从关系。而且要定期互换——你开一段我开一段。3.2 结对编程的好处书中从三个层次总结· 开发层次更好的设计质量和代码质量两人解决问题的能力更强· 个人层次更多信心高产出带来高满足感· 企业管理层次有效交流相互学习知识传递更高投入产出比我的思考结对编程在现实中争议很大。很多老板觉得两个人干一个人的活是浪费。但我的体会是结对编程最大的价值不是写得更快而是减少返工。两个人一起写设计缺陷当场被发现逻辑错误实时被纠正省掉的不是编码时间而是后续的调试和重构时间。当然不是所有任务都适合结对。探索性任务、复杂算法设计适合结对简单CRUD、重复性工作就没必要。一句话提炼结对编程不是两个人干一个人的活而是一个人干两个人的活——同时编码复审产出质量翻倍。04 | 与AI结对编程——知人善任第四版新增这是第四版新增的内容也是这一章最前沿的部分。4.1 AI也是结对伙伴第四版将结对编程的模型扩展到了人AI。AI可以扮演驾驶员生成代码也可以扮演领航员审查代码、提供建议。但书中强调了一个关键概念知人善任。不是所有任务都适合交给AI也不是所有AI都适合同一个任务。就像团队里不同人有不同特长你要知道AI的能力边界合理分配角色。4.2 我的实战体会做交付项目这一年我大量使用AI辅助编程。体会有三点第一AI适合做驾驶员的场景写样板代码、生成测试用例、处理格式化任务。这些任务机械但易错AI干得又快又好。第二AI适合做领航员的场景代码审查、发现潜在bug、提供优化建议。AI不替代人做决策但能帮你看到盲区。第三AI不擅长的场景理解复杂业务上下文、跨系统影响分析、涉及领域知识的判断。这些必须人来。核心原则AI是你的副手不是你的替身。决策权永远在你手里。一句话提炼AI结对编程的关键是知人善任——知道AI能干什么、不能干什么把对的活交给对的伙伴。05 | 两人合作的五个阶段书中借用团队发展的经典模型描述了两人合作会经历的阶段阶段特征我的理解萌芽阶段互相客气试探边界你说了算都可以磨合阶段意见冲突风格碰撞你这样写不对你才不对规范阶段建立共识形成默契这次你来写我来复审创造阶段高效协作112不用说话就知道对方要什么解体阶段合作结束各自上路项目交付各回各的如何正确给予反馈书中给出了反馈的三个层次最外层行为和后果——你这段代码没有处理空指针可能导致线上崩溃推荐中间层习惯和动机——你总是不写异常处理是不是觉得不重要慎用最内层本质和固有属性——你就是个粗心的人绝对避免好的反馈针对行为不针对人格。这条原则不只适用于代码复审适用于所有职场沟通。一句话提炼两人合作从客气到冲突到默契再到创造是正常路径。跳过磨合阶段的假和谐走不到创造阶段。干货复盘本章核心概念一句话理解常见误区代码风格规范简明、易读、无二义性能跑就行规范不重要代码设计规范函数只做一件事错误处理分层设计规范是架构师的事代码复审看代码是否在规范框架内正确解决问题复审就是挑刺结对编程驾驶员领航员平等互补两个人干一个人的活AI结对编程知人善任AI是副手不是替身AI什么都能干两人合作5阶段萌芽→磨合→规范→创造→解体跳过冲突追求假和谐本章最大收获合作的最小单位是两个人。代码规范是合作的地基代码复审是合作的保险结对编程是合作的极致形态。而AI时代的结对编程多了一个不知疲倦但需要知人善任的新伙伴——关键是想清楚AI能干什么、不能干什么决策权永远在自己手里。下篇读第五章团队和流程。如果这篇笔记对你有帮助欢迎转发给也在学软件工程的朋友。