成长的模式：如何从毕业生到技术专家？
过去的一个月里，在帮助其他部门进行毕业生培训。从名称上说是培训，但是实际上则是训战结合。不想一下子给太多，这篇文章会给的建议是：
寻找持续成长的动机
塑造整洁的编码习惯
建立定位问题的方式
学习既有的模式
频繁性自我总结
只凭这五点来说，与《福格行为模型》所定义的三要素也是颇为相似的：
要素1 动机（Motivation）：找到实现愿望的黄金行为
要素2 能力：让行为简单到随时顺便都能做
要素3 提示：善用锚点时刻让行为立刻发生
如果再简化来说，也可以采用和我一样的模式，通过基本简单的行为：每天写代码，每周做总结（通过文章）。
再定义专家
再回到我们这篇文章的主题里，如何从毕业生到一个技术专家？专家是基于研究、经验或职业并在特定研究领域具有广泛知识或能力的人。这样的定义是如此的简洁，以至于一个工作经验丰富的人都可以称上得是专家。在这种定义之下，一个 996 的程序员的开发经验，可谓不比一个 965 的人差。
于是乎，我还更喜欢，我在在那篇《专家 x 抽象 x 类比》里，我们也定义了专家应该做点什么？
所谓的专家嘛，就是在擅长的 “领域” 里，构建了具有范畴化（归类）的概念空间，并可以通过类比灵活地完善自己的概念库。
在这个定义之下，我们行业的技术专家便是指，在软件开发领域，具备丰富的软件开发相关的知识（即概念）或者是经验。拥有自己的软件开发相关的知识体系（概念库），并且能持续不断地完善。比如说，你是个后端专家，那么你能理解后端开发中的大部分概念，以及这些概念之间的关系。诸如于：
Spring Boot 是一个可以用于帮助我们开发微服务的框架；微服务是一种基于服务的分布式架构风格/架构模式；架构模式是模式的一种，其中采用最广泛的是设计模式；分布式架构通过远程协议连接多个部署单元。
基于 Spring Boot 构建的应用可以是一个部署单元，通过持续集成构建，并持续部署到容器化平台上。
能知晓整个体系的相关概念，并清晰地知道概念之间的关系，再有一定的经验，我们就是入门级 “专家”。而后，一旦来了一些新的概念，我们还需要能将它们纳入到我们的体系中。诸如于最近在后端开发领域又重新火起来的 Cells-based architecture，它也是一种架构风格，同等于微服务架构。我们所能构建的是一个领域的思维框架，它可以帮助我们对所有的知识分门别类。
1. 寻找持续成长的动机
首先，我们要思考的第一个问题是，为什么我们要成为一个技术专家？
不管动机水准的高低为何，人们若能维持一定的动机水准，则不但能维持追求该目标的行为，也能维持心理上对该目标的渴望，直到人们知觉到该目标达成为止。—— 维基百科
六年前，我参加过一个 Management 3.0（有兴趣的读者，也可以翻看《管理3.0：培养和提升敏捷领导力》）。虽然，这个培训确信了我不适合这个无聊的工作。但是，培训/书中介绍了一个 CHAMPFROGS 模型，它可以用来帮助我们寻找内在的动机。它由十种激励因素（好奇心，荣誉，接受，精通，力量，自由，亲和力，秩序，目标，地位），包括内在动机、外在动机或两者兼有的因素组成。（有兴趣的读者，可以翻看：https://www.infoq.com/news/2013/11/intrinsic-motivators/ ）
你也可以尝试一下，从上面的十个动机，按一、二、三的顺序，挑选出最与你匹配的动机。进而，你就可以发现你成长的动力在哪里。我记得多年以前，我的主要动机是好奇心、自由，其中有一个我已经忘了，估计也不重要了。
总有人会说：“hi，我成为技术专家的专家是赚更多的钱”。那么，问题来说，你如何定义多和少，怎么去衡量它们呢？对于打工人而言，你赚的钱多数时候，并不是靠你的能力决定的，而是你的行业决定的。所以，久而久之，将赚钱作为成长的目标，你会失去这种动力。因为，你的技术成长并不会从收入上得到回报。
2. 塑造整洁的编码习惯
整洁的代码意味着很多事情，你可以从《代码整洁之道》得到更多相关的知识。作为一个刚入行的程序员，在代码上充斥着大量的问题，诸如于：
无用的注释
注释的代码
混乱的代码风格
缺乏设计/重构的代码
缺乏自动化测试，导致大量的 println 或者 console.log
不会使用工具加速开发。如 IDE 快捷键、snippets、emmet 等
……
如果在工作一两年之后，你依旧还是这样，就需要警惕一下。基本的编程习惯都没有养成，离专业的程序员的距离就更加遥远。而这些简单的问题，大部分都可以通过 IDE 来帮助我们发现，如 Intellij IDEA 这一类的工具。
所以，我建议新手程序员应该优先考虑现代化的 IDE，从工具上花的钱，早晚会通过其它方式赚回来的。
3. 建立定位问题的方式
我们一直在说，程序员大部分是 ctrl + c/ctrl +v ，即 Copy and paste from Google/Stack Overflow/GitHub。但是呢，能做到这一点的程序员，本身并不多。学会使用 Google，是作为程序员的一个很大的门槛，而大部分人都跨不过这个门槛。另外一个门槛，便是访问 GitHub，大量的可学习的代码在上面。
从查看问题的角度来说，我们可以发现新手经常：
忽略到错误信息上显而易见的信息，如 error 等。
不会有效地看错误信息。只看最后的结果，或者截错图。
从分析问题的角度来说，我们还可以发现新手们：
不会去查看官方的文档。哪怕官方文档真的是最好的。
不懂得如何查看文档。
忽视从错误信息搜索，是最有效的手段。
不懂得如何使用关键字搜索。即采用相应的技术术语，如：Spring Boot JPA Query
不知道 GitHub issue 可以搜索
而在定位问题上，虽然对于新手有点难，但是依旧可以做一些尝试。诸如于通过 review 代码变更、回退，或者是自动化测试来帮助我们定位问题。
4. 学习既有的模式和最佳实践
对于新手来说，值得注意的是，我们在这一个阶段遇到的问题，大部分都是一些已知问题，往往可以搜索到资料来解决。大部分困扰你已久的问题，往往在书上，或者通过 Google 就可以得到这样的答案。
也因此，在多数时候，我往往会通常买书来快速熟悉一个现有的领域。没有什么能比，买知识更划算的知识。虽然说，互联网上也包含这些知识，但是搜索是需要成本的。对于编程来说，大量的知识已经被先辈们总结过。与其再自己汤坑，还不如直接买本书方便。所以，不妨去寻找一些书单，诸如于：https://www.douban.com/doulist/121444657/
广泛意义上的模式是一个好东西，比如如何去分析问题、拆解问题等等。
你也可以多去搜索看看，新手程序员的建议。
5. 频繁性自我总结
不要把日报、周报视为自我总结 。这是的总结是指对于技术、模式等的总结，它可以是：
如何应用某个框架和模式的总结
如何一步步采用某种框架的总结
分析某个框架的原理的阶段性总结
……
编程生涯很长，我们使用过或者将使用的技术很多。新的技术层出不穷，绝大部分的新技术都是基于已有的改进。与此同时，我们学习过的大量有趣的东西，并不会在工作的时候用上，或者用到的概率很多。
而如果我们不去记录这些有意思的东西，通过代码托管网站或者博客的方式，那么我们再次遇到它们的时候，就需要重到再来。所以，可以多做一些总结，以便于将来使用上。
其它：专家的知识诅咒
也是好久没有接触毕业生，所以过程中陷入过知识诅咒的问题。即如果我们很熟悉某个对象的话，那么我们会很难想象，在不了解的人的眼中，这个对象是什么样子的。。简单来说，就是无法预知毕业生的平均水平，需要多次的解释，才能将问题解释清楚。
对于我的文章来说，这个问题也是由来已久的。只是对于我来说，要解决这个问题并不容易，也不是我的义务。博客一直在那，或许，多年以后，读者就能自行理解。
对于专业的程序员来说，也存在类似的问题。我们习以为常的内容，在一些新手看来，往往是无法理解的，我们也很难解释清楚。在解释的过程中，还有可能带入了更多的概念，导致新手程序员更加困惑。诸如于，我在解释一个几百 M 的文件提交到 Git 中，为什么会存在的时候，引入了 blob、索引等一系列的概念。这时候的效果反而不如右键 .git 目录查看一下大小，来得简单得多。