絮絮叨叨的开场
上一篇需求的视角，我们介绍了一种可以让人回归场景的的小工具，避免在实现功能时的需求理解问题。但是在我们很好地理解了需求之后，在实现过程中，就会一帆风顺么？也不是的。
我们工作久了，就会发现有些人资质很好，有些人资质就很差。你会发现，有些人会考虑的比较有深度，有些人就不行。到底什么是深度呢？我不太能理解这个词，于是我继续观察。从外在看呢，我们会发现他们的行为表现有差别。我称之为工人的行为模式和工程师的行为模式。这两种行为模式在面对问题的时候差别尤为明显。
一个工人行为模式的人，遇到问题的时候，采取的方式就是直接把做过的行为再做一遍，期望能有所不同。比如装个环境，遇到问题了，就把执行的命令再执行一遍。
而工程师行为模式的人，遇到问题的时候，却什么都不着急做，往往是盯着出错的屏幕若有所思，片刻之后，突然说“哦，我知道了”，然后一下就把问题解决了，仿佛是在脑子里Debug。
我们打开看呢，你会发现他们的思考问题的维度是有差别的。我一直找不到一个好的模型来解释这种思维模式的差别，直到我在一本叫《创新算法》的书里面看到有个三轴分析的模型，可以较好的描述这个维度差别：
按照三轴分析的模型，我们思考一个机器，要从三个维度去思考，一是操作，就是人是怎么操作这个机器的；一是系统，就是这个系统都有哪些组件，这些组件都有什么关系；三就是因果，就是当人进行某种操作，到看到结果之间，一步步是怎么发生的，哪些组件起了作用，出了问题又是哪些组件没搭配对或者那个组件出故障了，或者操作本身是不是做错了。简单讲因果轴就是前两轴的动态关系。
计算机虽然精密，它也是一台机器，这上面跑的软件也没有任何的魔法，一样是适用于三轴分析的。
所谓像工人行为模式的人，其实就是指关注操作轴的知识，而对下面的系统轴和因果轴关心较少造成的。我曾经在面试的时候，让一个人讲他用到的一个框架的原理，结果他在白板上一顿乱画，我始终没看到组件有哪些，互相又是怎么配合的，最后发现，他是按照界面在描述那个框架的（很多框架都提供跟eclipse集成的GUI操作界面），他说的全都是在哪界面上填什么信息，然后就会有什么效果。只能用操作轴的信息来描述一款框架，这种行为也就是我们所谓的没有深度。
这样的例子在行业里比比皆是，我们在培训中就曾经碰到过一件哭笑不得的事情，比如在进行一些代码操练的工作坊的时候，让学员使用intellij来进行编程，一些有多年工作经验的学员写的代码出了编译错误，说这一定是你这个IDE的问题，我用eclipse这么写就没问题。当面用eclipse打开，依然是编译错误，就没话说了。还有远程就不会断点调试、配了log4j就抱怨e.printStackTrace()不打印了等等奇葩的例子就不展开聊了（但不写出来吐槽一下是真难受，我的一个朋友经常吐槽，为什么这个行业里这么多“业余”的人。说实话，我也是有点绝望的……），其实这些都是一个问题，就是只关注操作轴，关注的久了，所有的技能都只用操作轴的信息来编码，换个界面就武功全废，也是很多人觉得编程只能是青春饭的原因。
而工程师行为模式的人，一定不会只关注操作轴维度的信息，他们会打开系统，看到系统内部构造和系统到底是怎么运转的。由于对这些东西非常了解了，才能盯着屏幕上的日志，在脑子里模拟代码的运行，推理自己可能哪里出错了。
要想做到这一点，其实并没有什么魔法。我们用到的绝大多数框架、库、工具都是开源软件。开源软件都是很慷慨的把自己的机制、代码都放在了网上，完全没有信息壁垒。如果我们在读完入门案例后，还去读读Manual或Reference（有余力也可以读读源代码）我们不但会对系统的组件和系统的运转机制有更深入的了解，而且会在操作层面多一些新技能，当我们施展出来，还会有人惊呼“还有这种操作”。唯一需要做的就是认认真真读文档，照着文档写几个demo，编程初学者的话，把API doc都读读是最好的。然而这一件简单的事，竟然都成了少有人走的路。
所以对于开发人员来说，想要成为一名合格的工程师，只关注操作轴肯定是不行的，在学习的过程中要刻意的逼迫自己去关注系统轴和因果轴。不过这确实不是一件容易的事，不同于普通机器，软件的复杂度要高得多。咱们软件业有一句话说，没有什么问题是不能通过添加一个中间层来解决的（如果有就再添加一层），所以学习过程中会不断的发现，自己被一个抽象层挡住了。需要重新用三轴分析工具分析一下，抽象层的下面又是什么。学无止境，无尽的三轴。
本次讲的刻意练习其实是最简单的：阅读，写demo，这些都是优秀程序员的基本功。也是最难的一个，因为实在是太枯燥了，以刻苦的学习击穿认知的次元壁从来也是少数人才能达成的成就，但其实你仔细去观察那些少数人的时候，你会发现他们有些小技巧，能把苦变得有趣，这里就介绍几个小技巧。
Demo法
写一些小demo其实非常有助于建立起从操作到系统的映射，并可以通过下载开源代码及单步调试来理清中间到底发生了什么。由于demo都很小，很容易快速的建立收获感，你不会觉得做了很久没有任何收获，从而放弃。也不需要很大块的时间来做，导致每次学习都死于起手式。
我的前同事李鹏是此中高手，他有一篇文章《当我拿到一个前后端实现todolist的学习任务时，我应该怎么做？》中，把任务分解（我们下一篇就讲这个）和demo法结合在一起，大家感兴趣可以看看。受他影响，我也做了一个小github组织，来放自己的demo：https://github.com/jtong-demos 可惜最近几个月太忙就没时间更新了，不过也看出了另外一个优点，等我忙过这阵，想要捡起来的时候，这些demo会比网上的什么资料都快。
输出
为了深入到另外两个轴去，阅读当然很重要，但是对于大多数人来说枯燥是最大的退却原因。所以我在之前带学生的时候，都要求他们输出，写博客。有输出，枯燥感就会下降一些。但是写文章本身也很累，而且很容易变成抄书，所以我们后来又找到了另外一个工具：概念图。
可以用节点来表达组件，用线上的关系来表达组件之间的关系，非常适合表达系统和因果轴，可以更轻量的进行输出（具体怎么用，简书上一搜一大堆，我就不写了）。其实我之前介绍的C4，就可以看作是一种特殊的概念图。
小节
如前所述，我们学习软件相关的知识，可以借用三轴分析法，从操作、系统和因果三个角度扩展自己的认知。只有这样才能成为专业人士，刻意的阅读、输出、写demo，这简单的几件事，能做到的人却很稀有，这也是为什么优秀的工程师非常稀有的缘故，我们公司的数据，一个业务分析师或者QA，只要聪明，进入公司，差不多1年就可以比较独当一面，而开发人员，大都需要三年。大多数人都喜欢走易走的路，而难走的路反而是人少的捷径，坚持做好这几个动作，就是提升自己的捷径。