我最近一直在思考一个问题，在团队合作中，如何提升我们自己的技能？更重要的是，作为一名开发者，如何成为一名专业的开发人员？这是一个自然而然的过程还是需要有目的的追求特定领域的专业知识？是应该更注重自我学习，还是需要环境和自身相结合？关键问题是，如果我们能够了解其根源，就可以有目的的，有针对性的在团队中提升我们的专业知识，而不是被动的等待机会的到来。听起来是不是很有趣？主动“构建”而不是被动“等待”。现在的培训课程可谓是数不胜数，你可以去尝试了解，但是我从未见过一个资深的专家，仅通过培训课程就可以学习到所有的专业知识。这里最大的挑战，是如何衡量一个人是否是专家，他们拥有了足够多的专业知识就一定是专家吗？幸运的是，我不是第一个想到这些问题的人，所以，现在让我们来看看这个主题下一些现有的知识体系。
德雷福斯模型
如果你还不知道这个模型，德雷福斯模型是将一个技能的学习程度类比成阶梯式的模型。德雷福斯模型的适用性很广，定义一个人达到专家水平的五个发展阶段。
- 新手 —— 这个阶段的人喜欢明确的任务分工，当他们接到一个任务，唯一的期望是能够早日顺利完成这些任务。他们从来不考虑大局。他们急功近利，任何意料之外的事情发生，都会让他们感到焦虑。
- 高级新手。这个阶段的人，对于他们手头上的事，有一定的了解，能够快速的找到他们所需要的信息，但是他们对大局仍然不关心。他们能够在更高程度上使用专业的知识和技能，但当问题变得复杂，他们依旧会手足无措。
- 胜任者。能够看到全局，对不同问题及相应的影响范围有清晰的认知。当意外发生时，他们能够根据之前的经验独自解决问题。他们问题在于不能跳出问题本身去思考问题。
- 精通者。再遇到一个问题时，会首先从更高的维度去思考问题。能认知自己的技能与他人差异，能透过观察别人去认知自己的错误，形成比新手更快的学习速度。职位上：能明确知道自己的职位在整体系统上的位置。
- 专家。凭直觉做事，不再受限于规则和指南，持续的追寻更好的做事方式。
总而言之，德雷福斯模型认为，新手需要用规则和指南来指导他们做事的方法，而对于专家而言，这些规则和指南只会让他们束手束脚，无法充分运用他们的专业知识 / 直觉。在软件开发领域，严格的流程同样对初学者有益，使他们能够更高效的完成任务，但对于专家，更开放的环境才能让他们更好运用他们的能力。安迪·亨特在他的《程序员的思维修炼》中非常详细地研究了德雷福斯模型，表述了它在软件开发方面有利地一面。我认为，虽然模型本身没有问题，但是却忽略了一个很重要的问题。
它真的适用于软件开发吗？
将德雷福斯模型应用在软件开发，对于团队中的专家，可能是非常有利的，但却不利于我们在团队中培养新人。不仅如此，我认为严格的遵守德雷福斯模型，对一个新手的成长是有害的，甚至阻碍一个人专家的成长之路。
在软件开发中，向来没有明确的事情。如果我们的团队中有专家的存在，这是非常好的，但是没有也没有关系。现代软件的开发通常需要学习大量的知识，很多人究其一生可能最多也只能学会一种特定的专业知识，甚至无法完全学完。无论如何，你需要明白你需要什么样的技能是你需要的，明白自己的“边界”。成为某一领域的一名专家之前，你可能需要精通十几个不同的领域，其中任一领域的不足都可能阻碍你成为“专家”。
如果你尝试用德雷福斯模型创建一个团队，我劝你不要误人子弟，尤其在面对有特色的开发人员时。你曾经看到过让你叹为观止的代码吗？你想尝试吗？很多人都有这样的经历，无论我们在什么阶段。对待那些团队中新手，要向对待专家一样，让他们了解大局，不会有人会因此反感。用合适的方式指导新手成长，让年轻的开发者拥有更多成长和试炼的机会，真正有潜力的人会在这样的环境下发光发热。规则只会使人蹑手蹑脚，硬性的规则不如没有规则。僵化的流程和清晰明确的指导方针不应该是我们所的追求。没有一个现代化的软件项目是通过清晰的规则搭建的，我们越早适应这些不确定性，就会越早变得更具效能。
我们该如何成为专家
这仍然是未可知的。但可以肯定的是，德雷福斯模型是不可取的。但是，在团队蓬勃发展的过程中，这个模型仍然是值得参考的。除了团队成员的自驱力，以及在适合的时候给予其适当的帮助（资源），我不认为还有其他捷径可循。归根结底，雇佣优秀的员工，为其提供合适的成长环境，剩下的，交给时间。
