您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 业务知识 > 正文

技术的成长:如何从毕业生到技术专家?

发表于:2022-08-16 作者: 来源:Phodal全栈工程师

过去的一个月里,在帮助其他部门进行毕业生培训。从名称上说是培训,但是实际上则是 训战 结合。不想一下子给太多,这篇文章会给的建议是:

  • 寻找持续成长的动机
  • 塑造整洁的编码习惯
  • 建立定位问题的方式
  • 学习既有的模式
  • 频繁性自我总结

只凭这五点来说,与《福格行为模型》所定义的三要素也是颇为相似的:

  • 要素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 目录查看一下大小,来得简单得多。