47 携手共建

通过结对、群体编程和即时反馈共同构建代码，让设计知识在工作中流动而非事后移交。

学习目标

能为一条切片定义共同目标、协作角色、交付边界和即时反馈点
能用结对或群体编程让设计知识流动，并记录角色轮换与分歧处理
能在协作边界失效时定位首个差异，恢复共同所有权而不是制造新的单点

携手共建不是把人排成一列

本页依据 David Thomas、Andrew Hunt《程序员修炼之道：通向务实的最高境界（第2版）》，云风译，电子工业出版社，2020 年 4 月，ISBN 9787121384356 的公开中文目录，独立重构 47 携手共建。正文、代码、图示、实验和练习都是本课程重新设计的教学材料，不复制原书正文、插图或答案。

共同工作不是把代码按文件切给不同的人，然后在最后一天交换结果。它是一种设计协作：参与者共享目标，在代码形成的同时交换上下文，用短反馈尽早暴露分歧，并通过轮换减少知识集中。协作质量要看可观察的行为和交付证据，不看会议数量或座位安排。

三个会让协作变成表面配合的陷阱

五个词建立协作回路

<Term def="参与者共同认可、可观察且有完成边界的交付结果。">共同目标</Term>不能只是“把这个模块做完”。它应该说明用户结果、范围、验收信号和拒绝条件，才能让不同角色围绕同一个对象判断。

<Term def="两个或更多参与者在同一个问题上共享观察、决策和反馈的工作方式。">同步工作</Term>可以是结对、群体编程或短时设计协作。关键不在工具，而在参与者是否同时接触到输入、推理和结果。

<Term def="让错误、分歧和新知识在仍可调整时被发现并传回工作现场的信息。">即时反馈</Term>包括测试、运行观察、同伴提问和用户样本。反馈越晚，越容易把局部决策伪装成既定事实。

<Term def="有意交换操作者、导航者、审查者或主持者责任的节奏。">角色轮换</Term>让知识不依附在某个键盘、服务或会议发言人上。轮换不是形式动作，必须改变谁做决定、谁验证边界。

<Term def="团队能共同解释、修改、验证并恢复一段交付物的责任能力。">共同所有权</Term>不等于所有人都对所有细节熟悉，而是没有不可替代的知识孤岛，关键契约和回退路径能被多人重建。

协作回路从共同目标开始，经由同步工作产生即时反馈，再靠角色轮换扩大知识流，最后在复盘中更新共同所有权。任何一个环节缺证据，速度都可能只是把返工推迟。

专属图示：协作从共同目标出发，经反馈和角色轮换扩散知识，再回到复盘。

提示82：不要一个人埋头钻进代码中

这条提示的重点不是强制所有任务都两人同时操作，而是避免复杂决策在没有旁观者和反馈的情况下长时间积累。适合结对的任务通常有高不确定性、跨边界影响或需要快速学习的设计空间；机械且边界清晰的工作可以用异步审查，但仍需共享证据。

提示83：敏捷不是一个名词；敏捷有关你如何做事

敏捷协作可以被观察：小批量交付、快速反馈、可调整计划、角色交换和持续复盘。贴上“敏捷”标签却不改变工作循环，不能证明团队更能响应变化。一次协作实验应当记录参与者、输入、反馈延迟、决定和用户结果，而不是只记录站会是否举行。

type ReviewSession = {
  goal: string;
  driver: string;
  navigator: string;
  feedback: string[];
  unresolved: string[];
};
 
function canClose(session: ReviewSession) {
  return (
    session.goal.length > 0 &&
    session.feedback.length > 0 &&
    session.unresolved.length === 0
  );
}

这个检查只表达一个协作契约：没有目标、反馈或未决风险清单，就不能把工作标成完成。真实项目仍要把测试、审查记录和用户样本接入交付流程。

选择一条切片练习协作

Interactive lab

选择协作样本，定位知识流的首个变化

多人协作

输入证据

五人共同讨论一条跨服务切片，但责任、暂停条件和验证人没有先约定。

实际首差

目标节点：范围或验收信号不清，讨论开始替代可观察交付。

恢复动作

缩小切片，指定反馈负责人和反例验证人，再用小样本重启协作。

先确认共同目标，再选择协作样本；人数增加不等于反馈更快，证据必须随工作一起产生。

分步1 / 4

1. 选小切片并声明共同目标

选择一个两小时内可以观察结果的切片，写出用户结果、范围、拒绝条件、交付负责人和反馈接收者。确认所有参与者能用自己的话复述同一目标。

正常、边界与单一故障证据

专属图示：用正常、边界和故障样本验证共同所有权是否可被多人承担。

样本	只改变的变量	预期判定	必存证据
正常	明确目标、两名参与者和反馈	切片交付，设计理由可复述	目标、角色、测试和决策记录
边界	期限、人数或分歧复杂度	明确暂停或调整，不产生假完成	阈值来源、未决风险和负责人
单一故障	一个角色、反馈或工具失效	在首个协作异常点暴露并恢复	首差、上下文、回退和复盘行动

共享代码不自动产生共享知识。复核者要随机询问参与者如何改变行为、如何重放失败和何时拒绝交付；若只有一个人能够回答，团队仍然存在知识单点。

术语表

名词解释

本章出现的专业名词，用大白话再讲一遍。

共同目标: 参与者共同认可、可观察且有完成边界的交付结果。
同步工作: 两个或更多参与者共享观察、决策和反馈的工作方式。
即时反馈: 让错误、分歧和新知识在仍可调整时传回工作现场的信息。
角色轮换: 有意交换操作者、导航者、审查者或主持者责任的节奏。
共同所有权: 团队共同解释、修改、验证并恢复一段交付物的责任能力。

练习

问题 1： 两名开发者结对完成一个接口，但只有操作者知道为什么拒绝某个输入。你会如何修复这次协作？

问题 2： 五人群体编程中有人提出数据丢失风险，但大家想快速投票结束。你会怎么做？

问题 3： 团队宣布“我们已经敏捷”，但发布后仍由一个人处理所有故障。怎样设计协作回归？

本单元回顾

携手共建不是把人聚在一起，而是让共同目标、同步工作、即时反馈、角色轮换和共同所有权形成可观察的闭环。结对或群体编程只有在设计理由能被多人复述、失败能被多人恢复、反馈能及时改变决策时才真正减少知识孤岛；否则，标签改变了，工作方式没有改变。