一个“熟练”程序员和一个“有能力”程序员哪个更牛一点?

你知道“有能力”和“熟练”的区别吗？这听起来像一个具有欺骗性的问题，因为两个单词看上去似乎说的是一件事情，但是两者之间的微妙差异却正是关键点。

一个“熟练的”程序员与一个“有能力”的程序员哪个更厉害一些？

“有能力”的含义是使用足够的经验和知识将事情做完。

“熟练”意味着能够清楚认识到选择某种方式做事的原因以及此种做事的方式是否符合大的框架。

换句话说，一个能够熟练地做某件事情的人总是一个有能力做好这件事情的人，但反过来说可能就不成立了。

我们首先将“能力”定义为“我知道如何做事”。公平地说，不管你从事何种职业，知道如何做事都是相当重要的。如果你是个程序员，那么你的工作中的很大一部分是学习如何做事。知道如何做事虽然很重要，但是不要只为“知道如何做事”努力，否则你会很快发现自己失业了。

要知道在通向专家道路上，处于中间位置的程序员，都在某个层次止步不前（许多人甚至一辈子都停留在此处）：这些上流不属于上流，下流不属于下流的程序员会认为可以用所做事情的多少来区别新手和专家。他们的这种想法其实只对了一半！

此处就引出了“熟练”的含义。“熟练”的本质是关于“为什么采用这种方式做事情”——这是理解一个难题的各个部分与理解各个部分如何构成一个整体的难题的不同之处。

举个栗子，有能力和熟练之间的差距可以解释为什么有许多人都在高层次的编程思想之上挣扎，如设计模式。

一个有能力的程序员能够熟读备忘录模式，并且理解如何实现它。他们甚至能够识别出备忘录模式适用于何种应用场景（可能在GUI里实现一个undo操作）。但是由于他们不知道更大范围的框架性的东西，他们可能还是会错误地应用这种设计模式。

相比之下，一个熟练的程序员能够知道备忘录模式什么时候会失效（例如，如果正在拷贝大量数据，或生成大量副本时）。他们能够考虑一些替代方案与备忘录模式进行对比，从而考虑备忘录模式是否是最优的实现方案。他们也理解备忘录模式背后的基本设计思想，从而创造出一种能够更好的适应特定应用场景的定制化解决方案。

更重要的是，一个熟练的程序员总是能够识别出讨论设计模式的合适时机。就像向一个新手解释代码库的概念，一个熟练的开发者可能会重点说明代码做了什么，而不是抛出一堆设计模式的名字，之后告诉一个菜鸟“读完《Gang of Four》之前不要问我任何问题”。

模式、原则、**惯用法、库、语言特性，这些都是工具。但一个真正的熟练程序员会使工具适应工作，而不是让工作适应工具。

许多人从没有特别专注于开发的熟练度，因为坦率地讲，以一个有能力者的角度进行开发更直截了当。但是如果你想要改变自己做事情的角度，并且需要一些帮助以便更好的开始，这里有一些建议可以尝试：

解释你想要以某种方式做某件事的原因，但是不要说是因为“最佳实践”或者是社区指南。仅仅就当前需要解决的问题内容讨论解决方法的利弊。

学**更少更有价值的事情，之后尝试着将所学到的知识应用到不同地方，观察所学知识在哪里起作用，哪里没效果。使用失败的经验来发现自己真正所需的新工具，并添加到自己的技能库中。寻找那些其他人“打破规则”并获得成功的例子。偶尔也打破你自己的规则，看看这样做对你是有伤害、有帮助还是没有起到任何作用。

挖掘事情的本源而不是只知道大概。这会耗费更多精力，但能帮助我们找出某项技术的基础和边界，同时我们也会受到核心思想的启发而产生我们自己的想法。

将自己置于某个自己最不熟悉的工程中，然后试着在不依赖自己现有的工作流程、**惯和规则的条件下找到解决方法。询问其他人做事情的原因，但不接受教条式的理由。通过询问其他人，能够试着站在其他人的角度考虑事情。这样做有很大的价值，因为这能够让你认识到他们以自己熟悉的方式思考出的想法的优势和劣势。

选取一小部分自己能够使用但不精通的技能，试着将对这些技能的掌握程度从“有能力”变为极为熟练一致痴迷的程度。达到对整个知识体系中一小部分的掌握，比你所知的任何人都要高的程度。一旦你达到那种境界，再去检验那些很深很专一的知识的优缺点。

作为一名程序员，要一直探究不熟悉、不同角度、不精通的技术。只有这样你才能在“有能力”的基础上更上一层，才能脱离仅仅是“知道某些事情”的程度。

最重要的是：一旦你开始专注于以“熟练”为目标，有很大机会能够找到一条真正通往“精通”的道路。

程序喵