• 尋找持續成長的動機
• 塑造整潔的編碼習慣
• 建立定位問題的方式
• 學習既有的模式
• 頻繁性自我總結

只憑這五點來說，與《福格行為模型》所定義的三要素也是頗為相似的：

• 要素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 目錄查看一下大小，來得簡單得多。