2.5 技术协作
← 2.4 源代码管理 | 首页 | 下一节: 2.6 DevOps 实践 →
代码审查最佳实践
撰写 Pull Request 时
- 写清楚目的：探索？简化？修复？提供足够的背景，不假设读者知道历史。
- 明确需要什么反馈：快速看一眼？深入讨论技术方案？审设计？审文档？
- 标记 WIP（Work In Progress）说明状态。
- @ 相关人员并说明为什么请他们来看。
评审时
- 先了解上下文——这个 PR 为什么存在。
- 如有强烈异议，冷静片刻再回复。
- 用"你觉得……怎么样？"代替"不要……"。
- 解释代码需修改的理由：是风格不一致？有更好的方案？还是个人偏好？
- 避免"从来不要……""绝对不行……"等夸张措辞。
- 避免"蠢""烂"等贬损用语。
- 用 emoji 缓和语气：✨ 和 👍 能有效降低文字的冷漠感。
回复评审时
- 先表达感谢，尤其是面对混合反馈时。
- 对不理解的求澄清："我不确定你的意思，能具体说明吗？"
- 解释你的决策原因。
- 尽量回复每条评论。
- 链接到修改对应 commit：
Good call! Done in 1682851。 - 当讨论陷入僵局时，转为面对面沟通，然后写一个总结供后续参考。
结对编程（Pair Programming）
"Betty Snyder 和我，从一开始就是一对。我相信最好的程序和设计是成对完成的，因为你可以互相批评、找到彼此的错误、使用最好的想法。" —— Jean Bartik，ENIAC 首批程序员之一
"所有生产程序应由两个人坐在一台机器前编写。" —— Kent Beck
三种主要模式
| 模式 | 运作方式 | 适用场景 |
|---|---|---|
| Driver & Navigator | Driver 写代码（战术思维），Navigator 观察全局（战略思维），定期切换角色 | 日常开发 |
| Ping Pong | A 写失败测试 → B 实现使之通过 → B 写下一个测试 → 循环 | TDD 场景 |
| Strong-Style | 老手做 Navigator 口述设计，新手做 Driver 操作键盘。规则："一个想法要从你的头脑进入计算机，必须先经过别人的手。" | 知识传递、新人上手 |
关键收益
知识分享、反思讨论、保持专注、实时 Code Review、两种思维模式互补（战术+战略）、集体代码所有权、限制 WIP 提高团队吞吐量、新成员快速融入。
常见挑战与对策
| 挑战 | 对策 |
|---|---|
| 高强度消耗精力 | 番茄钟（25 分钟工作 + 5 分钟休息），每天不超过 6 小时结对 |
| 人际关系摩擦 | 频繁角色切换，开始前讨论"怎么配合"，结束时做 mini-retro |
| 会议打断 | 设定核心编码时段，作为一对一起参加会议 |
| 技能差距 | 避免 Navigator 陷入"微管理"模式——给 Driver 5 秒自己想 |
| 权力不对等 | 优势方需主动察觉并调整：分享键盘时间、鼓励对方提问 |
来源
- GitHub Blog — How to write the perfect pull request: https://github.blog/developer-skills/github/how-to-write-the-perfect-pull-request/
- Martin Fowler / Birgitta Böckeler — On Pair Programming: https://martinfowler.com/articles/on-pair-programming.html
← 2.4 源代码管理 | 首页 | 下一节: 2.6 DevOps 实践 →