作为开发人员或者其他技术人员，从一个新手变成一个熟手之后，就觉得自己应该差不多了，对于再度前进的方向会变得迷茫。很多开发人员缺乏稍微长远一点的规划，比如，问及开发人员：你两年之后希望和现在有什么区别。80%的开发人员会回答：我希望两年之后，技术比现在要好一些。这样的回答，只描述了量变，没有描述质变。也就是说，没有翻天覆地的变化。为了让我们开发人员及其他技术人员知道什么叫做质变，进而有一个新的目标，本文档尝试对质变这一问题予以说明，并就如何产生这样的质变提供一些建议。

---

高级才是真正为自己开发

对于技术人员来讲，按照德雷福斯模型可以分为五级：

新手：只能按照指令一步步地走。新手没有接触过当前行业，所以只能按照指令一步步地走完过程。

初级（高级新手）：能够完成一个局部工作。不需要给出指令，只需要给出一个局部工作的目标，初级可以完成这一局部工作，但初级没有形成全局概念，不知道自己所做的内容在全局所占据的份量有多重。

中级（胜任者）：能够完成全局工作。这一层面的技术人员，对于一个领域的方方面面都能够了解，在给定目标的情况下，可以独立完成一个项目，可以带人，不会频繁求助高级。

高级（精通者）：具备主动性，能够根据环境纠正自己的目标和手段。高级能够站在一个中立的层面考虑什么应该做，什么不应该做，怎么样代价最小，需要权衡付出与收益。

专家：凭直觉工作，每击必中要害。在长期的解决问题过程中，专家形成了丰富的经验积累，可以快速抓住问题的关键点。

以上的分级，有一个重要的分水岭——中级跨向高级。中级及以下（下称中级）都是为别人而开发，高级（下称高级）及以上都是为自己而开发。所以，在主动性，做的目的、手段方面，中级与高级都存在着本质的区别。以下就来看看这三方面的区别。

由被动到主动

人做事的时候，有着内在的动力来推动。作为中级，事情都是由别人安排的，自己不愿意主动承担责任。类似于这样的说话方式，会出现在中级身上：

怎么需求又变了，能不能把需求确定了再做

这样做不行的，框架已经定好了，只能按那样的方式来做

我辛辛苦苦写的这么多代码，又白费了

这个还是不要改了吧，改起来很难的，我担心出问题

这个问题不是我这边出的，是XX那边的接口问题

以上可以看到，中级作为一个被动完成任务的状态，会尽量让事情少摊到自己身上。并且会多有抱怨，因为对于中级来讲，一个不断改变的需求产生的原因总是别人的原因，与自己无关，自己只是一个代码的实现者。我们可以看看高级对应的说话方式大概会是怎么样：

这个需求为什么要改成这样，能跟我详细说明一下不，我看看是不是值得改一下

我跟架构组沟通一下，这样改一下应该可以让整个项目变得更加简单

我先做的这个原型，代价很小，我们已经确认了原型，现在我开始写代码做实现

我觉得这样改可以让整个项目更加简单，当然，直接一刀切会有很大的影响，我们看看怎么切过来

这的确是个问题，我来跟进一下，找一下原因

高级作为一个主动解决问题的人，会考虑到业务方的需求，对所需要付出的代价做一些权衡，不会推脱问题，会将问题先收下来，进一步去找问题的原因，会尽量让一个项目变得简单可理解，勇于根据现实的改变来调整当前的目标和技术手段。

从积极性方面来讲，一种主动积极的心态才能为自己创造更多的机会。中级被动的状态，把复杂的事情推脱掉，进而也阻断了自己解决复杂问题的机会，从而能力不能得到提升。中级会一个误区，认为可以自己通过看书，看视频来获得提升。但可以说，最有效的提升方式，就是通过实际地解决问题，让自己的能力得到提升。看书、看视频在能力提升方面起的作用是，在实际解决问题的过程中，会给一个思路，让人把问题给总结起来，加深对解决问题的理解，能够让解决特殊问题变为解决比较普遍的问题。

比如，在使用docker的过程中，如果只是看看书，看看视频，是无法知道docker容器之间的网络交互的。只有实实在在地使用docker做出来有价值的结构，在做这个结构的过程中遇到问题，并且解决问题，个人才能知道docker容器的网络交互是怎么样的，再配合看书，看视频，就可以很好地理解网络交互为什么是这样。

所以，如果中级没有在主动性方面有一个根本性的转变，中级就会停留在原地。同时，有了转变，就能够有着越来越多的机会提升自己，进而与中级快速拉开距离。这样的距离，就是一个分水岭，中级还是那个中级，但高级很快就不是那个高级了。

完成任务到表达自我

针对于同一个目标，中级与高级的处理方式有着不同的态度。中级是为了完成任务，所以接受到的目标越是清晰，越是不变，对自己来讲越是有利。实际上，我们所面对的大多数都是中级，这就迫使高级人员需要将目标描述得清晰、可视化。

高级对待同一个目标的态度是，这又是一次提升自我我机会，我要挖掘这一次机会的所有价值。目标不清晰，没有关系，我可以通过沟通来将目标弄清楚，这样可以锻炼我的沟通能力。框架有问题，没有关系，我可以尝试着做一定的修改，看看是不是那样做可以简化项目，这可以锻炼我的抽象能力。我一定要将这个项目做得很完美，无论是用户体验，还是代码格式，我都要写好，这样才能挖掘这一次机会的所有价值。咦，我发现代码有很多是重复的，嗯，我需要写一个代码生成器，生成那些重复的代码。我发现所有的

Dao 都有 insert/update/delete/select 方法，我可以写一个通用的 Dao，利用 java

的继承机制，这些方法就不会再写了。达成目标，就是把我方方面面的想法都表现出来的过程。这就是高级的表达自我的过程。

一个给定的项目，都有着现实的价值，也就是说，一个项目都有着对应的用户群体，做好一个项目，就是拿现实的、客观的评判标准来评判自己的想法是不是对的，自己做的事情是不是有价值的。中级不会考虑到这一个层面，所以中级只是简单地完成任务。高级则会考虑这个项目的价值在哪里，高级自己可以借助这一个项目过程印证自己的哪些想法。

被工具使用到使用工具

在确定目标之后，中级会使用自己熟悉的工具和手段来达成目标。中级作为一个胜任者，对于一个明确的目标，有着很熟悉的工具和手段，是可以完成目标的。同时，中级的极限也就是针对具体的目标，采用熟悉的手段达成目标。

高级对于一个目标的认知是，通过一个有价值的目标来确认自己的想法，所以不会受限于工具与手段，并且为了让自己的抽象能力得到提升，更愿意花时间去研究新工具、新手段，进而让解决问题的方式变得更加简单。高级会重视生产力这一概念，提升自己的生产能力。提升生产能力，主要就是提升个人使用工具的能力。

抛开工具，人与人之间差别是不大的。人与人的差别大距离拉开，就在于不同的人使用的工具不同，或者对同一个工具的使用有效程度不同。这里要注意：工具除了包含了扩展行动能力的交通工具，扩展表现能力的PPT、Word，扩展编码速度的Eclipse、Idea等，最重要的是，工具也包含了扩展思维能力的思维模式 。

实际上，人每使用一种新的工具，都要有与之相应的思维模式来匹配。比如，作为开发人员，不能用 Eclipse 的快捷键来对 Idea

起作用，要从 Eclipse 转到 Idea

，就需要把之前的一切思维习惯都改变掉。以下将介绍中级向高级转变的方法，本质上就是提供新的思维模式工具，让开发人员在使用新的思维模式工具的过程中，让自己产生改变。

---

高级开发必做的事情

我们已经知道高级与中级是一个分水岭。中级的极限达到了，就会止步不前，同时，一旦转变思维，就会由中级变为高级，高级在解决每一个问题的时候，都得到锻炼和提升，从而与静止状态的中级渐行渐远。有很多思维模式，作为一个不断改变的高级会慢慢地发现新的思维模式，这里将介绍几个入高级大门的思维模式，请大家务必掌握这几种思维模式，在解决问题、沟通与交流的时候，可以试着实践以下几种思维模式。随着使用的次数增多，如同打字一样，多得成为了自己的潜意识，这就为自己在本质上产生改变建立了基础。

建立溯因推理模型

关于推理，有两种主要方法：

演绎法：规则+情境=结果

归纳法：情境+结果=规则

这两种方法，演绎是根据规则，再匹配满足规则的情境，进而得到结果。比如

规则：所有人都要通过吃来维持生存

情境：李雷是人

结果：李雷要通过吃来维持生存

演绎，就是把一个抽象的规则使用具体地演绎（表达）出来。这就引发了一个问题——规则是怎么产生的？规则的产生，通常是由归纳法来产生的，归纳就是将多个相似的具体情境+结果进行抽象，进而得到规则，如：

情境1：孔子是人

结果1：孔子要吃饭才能活

情境2：曹操是人

结果2：曹操要吃西瓜才能活

……

规则：人都要通过吃来维持生存

这就是两种很常见的方法。有一种补充的方法如下：

溯因法/反证法：结果+规则=情境

这种方法通常用于提供创造性的新思路，先拿之前的例子看看这一方法是怎么样的：

结果：韩梅梅通过吃来维持生存

规则：人都要通过吃来维持生存

情境：韩梅梅是人

这实际上就是拿情境来验证规则，结果——韩梅梅通过吃来维持生存，是不是因为规则——人都要通过吃来维持生存——这一规则发生了作用呢？那就看一下情境是不是匹配：韩梅梅是人——这一情境是不是成立。对于中级来讲，他们通常会把复杂的问题抛出去，自己不去解决，所以，无法应用这一思维模式来解决问题，进而会变得越来越不灵活。高级则会应用这一思维模式，在遇到一个问题的时候，充分尝试各种可能性，并最终找到解决问题的方式。比如，遇到这样的问题

结果：手机端没有取到数据，怎么办

高级遇到这一问题的时候，大概一个一个按如下规则地去验证：

规则：本地网络有问题——情境：看看手机能不能上其它的网站

规则：服务端域名解析出错——情境：ping 一下域名，看看是不是有问题

规则：服务器停机了——情境：让运维登录一下服务，看看是不是停机了

规则：内存占用过高——情境：让运维看一下机器的资源占用情况，是不是内存、CPU占用过高

规则：用户权限被调整了——情境：了解一下最近有没有做什么修改

……

可以看到，面对一个问题，高级会寻找各种规则，并使用情境来证明是否被相应的规则影响。这一个过程，激活了高级的思路，让高级把所有经历过的规则再一次提取出来，一一使用，相当于复习了所有可知的规则。在已知的规则被穷尽的时候，就要创造性地突破自己知道的规则，寻找更多的信息，产生新的规则。对于手机端没有取到数据这样的问题，可能最后只是无意识地在服务器上敲击一个命令：

du -h

然后意外地发现磁盘已经满了，然后进而尝试着删除几个文件，又可以取数据了，接下来很快磁盘又满了，问题又出现了。进而判断应该是磁盘满导致的。然后再深究，我们写的程序没有记录日志啊，怎么就磁盘满了呢？结果通过以下命令一层层地寻找大文件：

du -sh *

发现大文件原来是 out，然后又想了一想，昨天李雷说安装了一个什么监控，不会是这个监控打出来的日志文件吧，然后问一下李雷……

通过这个过程，可以看到溯因推理可以让自己瞬间经历一次人生百态，把所有可能想到的问题都想到，必要时还需要创造性地构建规则，还要看运气……当这样的事情多了之后，类似的问题再度出现的时候，也许高级会是随口一说：是不是XXX有问题，然后一验证，果然是的。这就是专家，这就是凭直觉工作，这就是直接点中要害。但需要说明，没有反复多次的经历人生百态，反复多次地穷尽所有想法，是无法形成专家级别的直觉的。

具体怎么操作呢？当遇到一个问题的时候，人通常的反应是这样的：

这个我没有遇到过，我不会

老大，你帮我看看，我这里出了这个问题

老大，我已经想了所有能够想到的办法，你指点一下吧

老大，这个问题，我觉得是这个原因引起的，你帮我改一个配置看看/你帮我重新部署一下看看

我为什么不自己改配置/部署？我不知道怎么改/部署啊

要把这样无意识的反应变为这样（注：以下是内心的独白，有些被系统屏蔽的话，的确是问题很烦人，真不想继续下去了）：

这个问题应该是这个原因引起的，我验证一下

我*，不是这个原因，我再看看是不是因为这个 

我*，又不是这个原因，是不是服务器有问题呢，重新部署服务器好麻烦哦，我先看看配置是不是可以改一下（评估付出与收益）

这个已经在用了，直接改配置影响很大，我**的要自己部署一个，真麻烦

晕，启动报错，看看是什么原因

我晕，还要下载另外一个依赖包

终于部署好了，我**，还要不要人活啊，不是这个原因

已经搞了5个小时了，他*的

……

我*，真搞笑，原来就是配置文件上多加了一个 “/”

这样的解决问题过程，收益不在于最终的结果，而是挖掘了高级所有的能力。

建立抽象-具体思维模型

抽象-具体的思维模型，与归纳-演绎推理相对应。这里提出这个模型，是把这一模型当作验证自己是否真的弄明白了一个事物的本质的工具来介绍。高级在解决问题的时候，不仅仅以找到问题的解决方案为目的，而是通过不同的人生百态经历，找到相似的东西，提炼相似的东西，在提炼的基础上再度进行抽象。比如：

情境1：孔子是人

结果1：孔子要吃饭才能活

情境2：曹操是人

结果2：曹操要吃西瓜才能活

……

规则：人都要通过吃来维持生存

这是第一个层面的抽象，进一步挖掘和提炼，可以得到更抽象的规则：

动物都要能够吃来维持生存

动物和植物都要有吸收和排放

生物的本质就是新陈代谢

在描述一个规则的时候，又要针对不同理解层面的人，给出不同的具体解释，就是见人说人话，见鬼说鬼话。如果高级能够在抽象与具体两个层面做到越是深入，则高级越是能够以最小的代价记忆规则，同时又能够将最高层面的抽象规则自由应用于不同的场景。

认识生产力概念

生产力，以直白的语言来描述就是，提高生产力的结果就是：减少投入，扩大产出。提高生产力的手段是：改变生产工具。需要再度说明工具包含了扩展思维能力的思维模式。对于所有人而言，人的产出只可以分为两类：

消费资料：生产出来的产品，是给别人使用和消耗的

生产资料：生产产品的时候所依赖的物质工具

比如，开发团员开发出来一个办公系统，给企业员工使用，这个办公系统，对于开发人员就是消费资料，对于企业来讲，就是生产资料。开发人员在开发办公系统的时候，所用到的技术框架，编码工具，电脑，服务器等，就是开发人员的生产资料，使用相应的生产资料又需要开发人员必备与生产资料相适应的思维模式。

如果要提高开发人员的生产力，开发人员把时间都花在做项目，就相当于把时间消耗在使用既定的生产资料来得到产出。同时，也就没有时间打磨生产资料，让生产资料变得更加强大。从而使得开发人员的能力受限于相应的生产资料和相应的生产模式。所以我们要在生产资料方面做持续的投入，这种投入包含了工具的投入和思维模式改变的投入。

比如，在我们现有的开发中，生产资料经历了 gnif1.0 gnif2.0 到目前的 gnif3.0 的变更，相应地，需要开发人员掌握三种框架所需要的思维模式。我们的开发环境由原来的手动打包变为现在的自动构建，与此同时，需要开发人员改变对打包的理解。

对于高级来讲，高级会有意识地为生产资料留时间。或者说，极端一点，宁可加班多花时间把生产模式改变了，然后使用新的生产模式来做生产，也不愿意快速地为了完成任务而使用固定的模式低效地达成目标。高级的积累，就是生产资料的积累。

比如， Emacs 作为一款好用的编辑器，在大多数情况下，它的生产力要高于一般的编辑器。比如，它可以：

作为命令行终端，运行各种命令

作为文件管理器，移动、复制文件

作为笔记本，记录各种笔记

作为日历，对重要的事情做提醒

作为文档编辑器，可以很好的组织和规划文档

作为代码编辑器，可以对几乎所有代码进行高亮显示

作为Lisp的入门语言，让人接触一种表达能力更强的语言

如果有一些功能不存在/不如意，可以自己开发/修改

这样的编辑器，是越用越高效，是值得让个人的思维模式与这样的工具匹配的。之所以越用越高效，就体现在它是生产资料的积累这一点。

又如， Idea 作为能够更加快速智能提示的工具，比起 Eclipse 来讲，能够提升 Java 代码的编写速度，也是值得从 Eclipse 转向使用 Idea 的。

高级心中的座右铭是：工欲善其事，必先利其器。

由被灌输变为分享

作为中级，眼界会受限于自己所使用的工具和模式，有些中级在完成特定目标的时候，遇到自己熟悉的工具手段，这时候他达成目标的速度有可能比起高级还要快。这个时候，中级会倾向于认为自己掌握的东西是一种绝活、必杀技，他是不愿意分享经验给大家的。作为高级，时时处于改变的状态，他们非常确信明天的自己比今天的自己懂得更多，所以有着将自己的经验分享出来的基础。也就是，中级认为资源是匮乏的，高级认为资源是丰足的。

分享的过程，也是将想法拿出来的过程，这一过程可以有以下好处：

让自己想法与别人的想法碰撞，得到更好的想法

把自己的想法拿出来，让大家来印证，从而让自己的想法有更广泛的适用性

分享的同时，也为被分享创造了条件，个人可以免费获得自己经验不到的信息

高级会在适当的时候将自己的想法分享给高级，从而收获到更多。

---

写在最后

对于技术人员，从中级转向高级，首先要从理念层面做出改变，由被动做事变为积极做事，主动沟通，提供有价值的想法，让自己的想法得到印证。其次要将文中提及的四种思维模式由有意识地去实践变为无意识地运用自如。