软件开发是团队运动

设计师和工程师彼得·斯基尔曼（Peter Skillman）设计了一个实验：他挑战了由四人组成的团队互相竞争，进行 “棉花糖挑战”。规则很简单——使用以下材料搭建一个能支撑棉花糖的最高结构：

这个实验的目的并不是解决问题本身，而是观察团队如何合作解决问题。在实验中，斯坦福大学和东京大学的商学院学生团队与幼儿园孩子们竞争。你猜谁赢了？

商学院的学生首先检查了材料，讨论了最佳策略，并小心选择最有前景的方案。他们的行为显得专业、理性、聪明，但最终幼儿园孩子们总是获胜。孩子们没有决定最佳策略——他们只是开始动手实验。他们站得很近，短时间内就进行交流：“这里，不，还是这里！”

孩子们赢得比赛并不是因为他们比商学院的学生更聪明或更有技能，而是因为他们作为团队的合作性更强（Coyle D., 2018）。

你在体育中也能观察到类似现象：你可以将最好的球员聚集成一个团队，但如果他们没有形成一个优秀的团队，他们仍然会输给一个技能较差但默契配合的团队。

在软件工程中，我们希望拥有高凝聚力的团队，而不仅仅是个别的专家在一起工作。我们要的是团队成员像 “棉花糖实验” 中的幼儿园孩子们一样，共同实验、相互合作。为此，我们寻找所谓的 E 型团队成员，作为 T 型团队成员的进化版本。I 型专家在某一领域有深入的经验，但在其他领域几乎没有技能或经验。T 型人是通才，在某一领域有深入的经验，但在多个领域也有广泛的技能。进化的结果是 E 型人——E 代表经验、专业、探索和执行。他们在多个领域有深厚的经验，并且有经过验证的执行能力。他们始终保持创新，并渴望学习新技能。E 型人是将不同领域的专业知识结合成高效协作团队的最佳方式（Kim G., Humble J., Debois P. 和 Willis J.）。

你可以通过查看一些拉取请求（pull requests）很快了解团队的协作情况。谁在做代码审查，讨论的主题是什么？大家讨论的问题有哪些？语气如何？如果你曾经看过高效团队的拉取请求，你会发现，一些问题会很容易显现出来。以下是一些常见的拉取请求反模式，你可以轻松地识别出来：

稍后我会向你展示代码审查的最佳实践，并介绍如何避免这些反模式。首先，让我们更仔细地看看什么是拉取请求。