代码审查是技术主管最高杠杆活动之一：它既保护质量又传授知识。目标是更好的代码和更强大的团队，而不是把守。审查应该快速、友善，并专注于重要的事项。
原则
text
✓ Review the CODE, never the person ("this function" not "you")
✓ Distinguish must-fix from nice-to-have (label nits explicitly)
✓ Ask questions, don't issue commands ("what about X?" invites discussion)
✓ Praise good work, not just problems
✓ Be fast — a PR blocked for two days kills momentum
✓ Approve when it's good enough, not perfect
一个具体例子
不要写"这是错误的，使用 map"，而是写："nit: 这里用 map 可以避免嵌套循环，值得吗？不阻塞。"同样的意思，但它更具教学性，留有商量的余地，不会阻塞合并。
注意权力动态
作为技术主管，你的评论分量更重。一个随意的"我会采用不同的方式"可能会被理解为命令。要明确说明什么是真实的关切，什么是偏好，并让人们可以提出异议。
为什么这很重要
审查设定了团队的质量标准和情感基调。
严厉的审查让人们变得防守性强，交付速度慢。
好的审查能发现错误、传播知识、让工程师变得更优秀，随着时间推移产生复利效应。