下载掌阅APP，畅读海量书库
立即打开
设计师兼工程师彼得·斯基尔曼做了一个实验：他让四人一组的团队在棉花糖挑战中相互竞争。挑战的规则很简单——用以下材料构建能支撑一个棉花糖的最高的结构：
●20根生意大利面
●1卷透明胶带
●1根绳子
●1个棉花糖
这个实验并不是针对问题本身，而是关于团队如何共同努力解决问题。在实验中，来自斯坦福大学和东京大学的商科学生团队与幼儿园的孩子们竞争。猜猜谁是赢家？
商科学生检查材料，讨论最佳策略，仔细挑选最优方法。他们以专业理性和智慧的方式行事，但幼儿园的孩子们却是赢家。幼儿园的孩子们并没有决定最好的策略——他们只是尝试并开始实验。他们紧紧地站在一起，简短交流：“这里，不，是这里！”
幼儿园的孩子们并没有因为更聪明或更熟练而获胜。他们获胜是因为作为一个团队他们合作得更好（Coyle D., 2018）。
读者也可以在体育竞技中观察到同样的情况：可以把最好的球员放在队伍中，但如果他们不能组成一个良好的团队，就会输给一个技术不那么好但能完美合作的团队。
在软件工程中，企业需要具有高凝聚力的团队，就像棉花糖实验中幼儿园的孩子们那样一起实践的团队，而不是仅在一起工作但互相独立的专家。通过寻找E型团队成员取代T型团队成员的演变来做到这一点。I型人员在一个领域有很丰富的经验，但在其他领域的技能或经验很少。T型人员是在一个领域内拥有丰富经验的通才，并且还拥有跨越多个领域的技能。更高级的是E型人员——E表示经验（Experience）、专长（Expertise）、探索（Exploration）和执行（Execution）。他们在多个领域拥有丰富的经验，具有成熟的执行技能，总是勇于创新，渴望学习新技能。E型人员是将不同领域的专业知识结合成一个高协作团队的最佳选择（Kim G.、Humble J.、Debois P.和Willis J.）。
通过观察一些Pull Request，可以很快观察到团队是如何合作的。谁来审阅代码，审阅的主题是什么？人们在讨论什么问题？语气如何？如果读者曾经见过杰出团队的Pull Request，就会很容易发现进展不顺利的事情。以下是一些常见的Pull Request反面案例：
●Pull Request数量过大，变化较多（批数量过大）。
●Pull Request仅在某个功能已经完成或在冲刺的最后一天产生（最后一分钟通过）。
●Pull Request通过但没有任何评论。这通常是因为人们只是为了同意而不干扰其他团队成员（自动通过）。
●评论很少包含问题。这通常意味着讨论的是不相关的细节，比如格式和样式，而不是架构设计问题。
后文会详细阐述代码检查的最佳方式，以及如何避免这些反面案例。接下来深入理解什么是Pull Request。