每日短讯：技术的成长：如何从毕业生到技术专家？
2022-08-16 09:59:49来源：Phodal全栈工程师
只凭这五点来说，与《福格行为模型》所定义的三要素也是颇为相似的：
(资料图片仅供参考)
如果再简化来说，也可以采用和我一样的模式，通过基本简单的行为：每天写代码，每周做总结（通过文章）。
再次定义专家再回到我们这篇文章的主题里，如何从毕业生到一个技术专家？专家是基于研究、经验或职业并在特定研究领域具有广泛知识或能力的人。这样的定义是如此的简洁，以至于一个工作经验丰富的人都可以称上得是专家。在这种定义之下，一个 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目录查看一下大小，来得简单得多。
