你們在尋找的高級程序員究竟是什麼樣子的？

若是第二次看到個人文章，歡迎「文末」掃碼訂閱我我的的公衆號（跨界架構師）喲~

每週五11：45 按時送達。__固然了，也會時不時加個餐～

個人第「110」篇原創敬上

你好，我是Z哥。

這篇文章主題很簡單，就是一個很常見的話題「什麼是高級程序員？」。

文章稍微長了些，可是很容易閱讀。

咱們的中國文化，對「面子」看的特別重，因此你會發現身邊處處都是高級XXX，聽着倍兒有面子，程序員也不例外。

可是你真要問每一個人，你認爲的高級XXX是什麼樣子的。估計每一個人都有不一樣的回答。

我還記得在我剛開始從事編程工做的時候，對坐在邊上不遠的那位我心目中的高級程序員的印象是：

工做至少有六、7年以上，能寫一個用起來很方便、看起來很牛逼、可是不太容易讓初級人員看懂的框架。

前兩天，我把這個問題丟到羣裏，你們給出的答案中，佔比最高的是如下幾個。

• 有 N 年以上編程經驗（大部分都說5年以上）
• 有出版過技術圖書
• 對某領域內對經常使用框架原理有了解，而且實際使用超過2年
• 能夠隨時隨地快速寫出常見的一些算法
• 至少封裝過一個被全局使用的開發框架
• 寫出來的代碼，閱讀起來很好理解
• 能帶領其餘人員成功完成項目

你看，這件事對你們來講就是常說的，「一千我的眼中有一千個哈姆雷特」。

不過這也正常，畢竟像初級、中級、高級這種高度抽象的詞彙，想要獲得一個可描述的定義與人交流，必然須要夾雜着我的的主觀因素。

可是不少行業都在這麼進行分類，天然有它的道理和好處。

我以爲其中最大的一個好處剛好是「主觀」的附屬品——「彈性」。

好比，我如今想招一位高級程序員，面試的時候無論是經過仍是不經過，我都有理由來解釋我對「高級」的定義。如此一來，我對陌生人的判斷就有了更大的「彈性」。

這實際上是面試官的一種權利，也是長期以來面試者總在面試中處於下峯的緣由之一。

事物老是有兩面性的，咱們在對陌生人彈性的同時，間接的也對內部的人彈性了，會致使內部的一些人才培養出現問題。

好比，你以爲內部的高級程序員不夠，但願能在外部招聘的同時，從內部也培養一些出來。可是此時，你又面臨了須要定義什麼是「高級」的問題。

若是無法定義一個可以達成共識的標準，又如何指導培養的方向呢？只能是一句空話。

長期以往會致使更嚴重的問題：真正的高級程序員不夠，只能讓中級程序員頂上。頂替的時間長了，會讓一些中級程序員誤覺得本身已經達到了高級水平。

在我平時的面試中，這樣的案例家常便飯。網上流傳的工做10年 = 1年重複10次的段子是真實存在的。

下面我來聊聊我對「什麼是高級程序員」的我的見解，歡迎你和我一塊兒探討。

無論是什麼行業，什麼崗位，在這個高度分工協做的現代社會，所需的能力主要分爲三個維度。

• 專業能力
• 鏈接能力
• 領導能力

我對程序員在這三個維度的理解大體是如下這個樣子。

先賣個關子，文章的最後我會將這三個維度組合起來，你會發現一片新的天地。

根據這三個維度的水平差別，咱們對初級程序員、中級程序員、高級程序員作一個簡要的描述。

01 初級程序員 - 知道有事要作 

處在初級階段的時候，咱們的精力大多隻會專一在專業能力的提高上。這個時候「領導能力」和「鏈接能力」是很弱的。

因此，這個時候哪怕你有強烈的好奇心也沒法很好的表達出來，大多隻能被動的接受工做安排。

在這個時期作事情須要依賴一些教程、文檔，只能「依樣畫葫蘆」，幾乎不能在不借助外部信息的狀況下解決以前從未遇到過的新問題，因此百度、Google就成了他們惟一的選擇。

你能夠在你的身邊觀察一下，若是常常有如下這些場景出現，大可能是初級程序員的表現。

• 很難提出正確的問題，大多會直接問別人這個功能應該怎麼作。若是你清楚地向他解釋，他就會徹底按你說的去作，甚至你寫的示例代碼都會copy過去。由於在他們的世界裏，只有編譯成功和編譯失敗，任務完成和任務未完成。
• 常常犯錯誤，因此會預留過多「彈性時間」，以便有時間在到期日以前重作。因此總會抱怨「沒時間」。
• 對與本身有工做交集的人員的職能沒有認識。好比，對測試人員老是充滿敵意的，由於他們發現了錯誤，「阻礙」了本身完成工做。
• 還沒注意養成一些好習慣，好比習慣性的提煉重複代碼、編寫風格一致的代碼、自測等等。

很遺憾，看似很初級的階段，並不僅是剛踏入工做的程序員所屬，在實際工做中，也有很多工做多年的人還處在這個階段。

02 中級程序員 - 知道如何作某事

對人羣按照單一維度進行劃分，大多數時候都是符合正態分佈的，這裏也不例外。中級程序員是咱們身邊最多的，包括那些不得不穿上高級程序員馬甲的中級程序員。

在這個階段，有些中級程序員開始具有了必定的「鏈接能力」，但並非全部人，主要看是否是擁有了「共同體意識」。

在專業能力上，中級程序員已經明白了必定的「總體與局部」的概念，但仍然看不到整個「森林」，大多侷限在某個模塊、流程上。好比，他們會想「這是作敏捷的正確方式嗎？」，但不會考慮「這對整個團隊、整個公司會產生什麼實際的影響？」。

他們開始注重代碼質量，由於擔憂低質量的代碼會影響他們視野中的「總體」。

可是對於質量的理解仍是比較單一。好比，這個時候你會常常聽到他們把「性能」掛在嘴邊，在他們心目中「性能」的地位是至高無上的，老是想着你這個方案和個人方案哪一個性能更好。

一樣能夠觀察一下週圍，中級的開發大多數會這樣作事。

• 針對一個問題，能夠提出多個方案，可是沒法作出準確的決策。一旦更權威的人給出了他的選擇，中級程序員就會不假思索的按照建議執行。
• 能夠看出代碼中的一些設計模式，可是本身寫代碼的時候除了單例和工廠，其它的幾乎想不到。
• 在討論一些時髦的框架和技術的時候總能聊上幾句，可是追問這個框架或者技術有什麼缺點，基本說不上來。甚至，草率的在項目中運用上這些時髦的框架和技術，最終致使線上問題頻發，不得不讓高級程序員來收拾殘局。
• 可以對本身完成任務所需的時間有準確的評估，可是評估他人的時間不會因人而異，也會以本身做爲標準來評估。
• 對與本身有工做交集的人員的職能有了必定的認識。好比，會主動尋求測試的配合，幫助本身交付更高質量的項目。

其實這個階段是最危險的階段，由於最可怕的不是無知，而是隻知其一;不知其二。心理學中的鄧寧-克魯格效應(The Dunning-Kruger Effect)講述的就是這個問題。

兩位社會心理學家在1999年作的4項研究，證明了下面的這個曲線的存在。

在這種狀態下，人最容易高估本身，這也是不少致使產生不少「假高級程序員」的緣由所在。

03 高級程序員 - 知道必須作些什麼

高級程序員在「專業能力」、「鏈接能力」、「領導能力」這三個維度都有所建樹。由於他們不但能夠把從1到100的事情作得很好，也有能力帶領其它人完成0到1的事情。

根據我身邊所接觸的程序員羣體來看，我所認爲的高級程序員，他們明白沒有什麼是完美的，相反，問題、缺點和風險老是存在的。

他們的決策老是站在爲了總體的「平衡」角度去考慮，而不是技術的酷炫或者外界流傳的所謂「正確的」技術。

他們會更多的關心那些不顯而易見的東西，如可維護性，可擴展性，易閱讀，易調試等等。

高級程序員就比如社會中的成年人，他們踩過足夠多的坑，也填過足夠多的坑，已經認清了現實的殘酷，尋求適合而不是完美。周到、務實、簡單，是他們作事的時候強烈散發出的「味道」。

能夠根據下面的這些場景來看看你身邊有多少「有味道」的高級程序員？

• 與初級和中級程序員不一樣，他們拋出問題不是爲了正確的作事，而是作正確的事。他們會詢問爲何要這樣作以及你想要實現什麼。當你告訴他們目標是什麼後，他們或許會經過暗示這種方式是錯誤的而另外一種更好來作出一些修正；固然，更重要的是還會提供論聽說服你。
• 由於提早明確了作事的目標，因此在動手作一件事的過程當中，他會在關鍵細節思考有沒有更好的方法，甚至是那些不在以前的討論範圍的新嘗試。
• 他能夠輕鬆地認可他不知道什麼，而且向你請教。同時也能夠輕鬆地向他人講清楚他所知道的事情。
• 他們理解合做的人員的職能的做用，不但知道何時向誰尋求幫助，還知道本身如何更好的幫助他們。
• 困難的事交給他們很放心，由於他們擅長的不是某種技術，而是解決問題的能力。他們總能解決那些以前從未遇到過的新問題，哪怕它們很困難。

那麼，怎麼作有助於咱們成爲高級程序員呢？

01 關注技術之餘還要關注業務

爲何把它放第一點，由於我以爲這點最重要，是其它項的基礎，也最容易作到。可是不少程序員不肯意去作。

必定要搞清楚業務目標，不搞清楚不開工。相信我，只要是一位合格的leader，必定會不厭其煩的和你說清楚的。

而後要習慣基於業務目標去分析可能會面臨的技術挑戰。好比，多少流量，涉及哪些用戶角色和功能，複雜度有多大等等。

再帶着下面的「不可能三角」去尋找合適的技術框架、解決方案。儘量的尋求最優的平衡，而不是走極端。

若是拿捏不許，能夠將多個方案各自的優缺點羅列出來，向Leader尋求建議。

02 「設計」代碼而不是「寫」代碼

通常人可能拿到需求，就開始寫代碼了，寫着寫着因爲頁面功能愈來愈多，感受代碼愈來愈複雜，本身都會以爲難以維護了。

雖然說要作好設計離不開大量的實戰經驗的積累。可是仍是有些方法可讓塑造這個能力的過程更快一些。好比，

1. 首先就是前面提到的第一點，多關注業務。不瞭解業務，你啥都設計不出來。或者把馬設計成了驢……
2. 若是某個功能的開發/修改，以「天」爲工時單位，必定要先畫圖。具體畫什麼圖，能夠參考我以前寫的文章：軟件開發中會用到的圖。
3. 搞明白每一個設計模式的特色和適用場景，注意，不須要把代碼怎麼寫背下來。只要你每次寫代碼以前掃一眼設計模式的列表，看看有沒有適用的。若是有的話，再去「依樣畫葫蘆」按照設計模式去實現，通過時間的積累，慢慢地，你真正掌握的設計模式就愈來愈多了。這有助於鍛鍊你的設計能力。

03 「接」需求以前會先「砍」需求

要作這點還得依賴於第一點，不然，你提出的「砍」需求建議大可能是不會被採納的。

不少人在聽需求講解的時候，思考的是，這個功能能不能實現、怎麼實現、難不難。大多數的提問也是基於這個思路展開的。

可能也會提出「砍」需求的問題，可是理由大可能是這個實現起來太麻煩了，這個無法實現之類。

其實只要你時刻保持着「作這個需求的目的是什麼」這個問題去思考，「砍」需求會變成一件更容易成功，並且天然而然的事情。

04 解決一類問題而不是一個問題

不少人以爲，天天看到bug清完就萬事大吉了。哪怕同一個問題在生產環境出現屢次，最多也就說一句「不會吧，怎麼又出問題了」。

這種對待問題的方式只會讓你愈來愈忙，由於你的解決問題效率與投入的時間多少是成同比變化的。

咱們要習慣於解決掉一個bug以後，想一下可否經過什麼方式找到現有代碼中的同類問題，並把它們處理掉。

甚至是考慮有沒有什麼辦法可以一勞永逸的避免此類問題再次發生，好比封裝一個SDK或者寫一個組件，儘量用一種低侵入的通用方式將問題扼殺在搖籃裏。不但讓本身輕鬆了，也造福了你們。

05 遵循KISS原則，寫儘量簡單的代碼

KISS 原則：保持簡單，愚蠢（Keep it simple, stupid）。

不僅僅是程序員，任何化繁爲簡的能力纔是一我的功力深厚的體現，沒有之一。

越簡單，越接近本質。就比如，有的人要用長篇大論才能講明白一件事，而有的人只要作一個形象的比喻你就懂了。

這個「簡單」指的是總體的簡單，而不是經過局部的複雜讓另外一個局部簡單。好比，爲了上層的使用更加傻瓜化，底層封裝的代碼錯綜複雜、晦澀難懂，這並非真正的「簡單」。

若是你自認爲已是一箇中級或者高級程序員了，那麼你回頭去看看本身仍是初級程序員那會寫的代碼，就會很容易發現一些顯得冗餘的代碼。

第二點提到的——「「設計」代碼而不是「寫」代碼」對作好這點有很大的幫助。

06 選擇忍受某些問題

在人工智能還不能代替咱們coding以前，咱們永遠要親自面對無窮無盡的、這樣那樣的問題。

然而，任何事物都有兩面性的，一個方案在解決一個老問題的同時，總會帶來新的問題。因此，咱們必定要意識到，忍受某些問題是必然的。

那些你如今看起來很傻逼的設計，可能就是當時的人作出的妥協。

因此，既然如此，你更應該考慮的是，當前的這個問題如今到底有沒有必要解決？值不值得，爲何以前沒去解決？它是否是你當前全部待解決問題列表中優先級最高的？

07 打造本身的「T型」專業技能

可能不少人都聽過「T型人才」的概念，咱們程序員在專業技能的打造上也適合用這種模型。

可是對於「先豎再橫」仍是「先橫再豎」可能不一樣的人有不一樣的見解。

個人觀點是，大多數狀況下，先豎再橫。特別是某個技術、領域發展的越成熟，越應該如此。

由於不少事物的本質是同樣的，因此對某一個領域達到很是深刻，洞察到一些本質的東西以後，對其它相鄰的領域有舉一反三的效果。能夠加速本身在「廣度」上的擴展。

不過，「廣度」也不是說走馬觀花，只知道最表象的「它是什麼」。我認爲比較合適的程度是，能夠不用清楚某個技術具體的使用方式，但得知道它能夠解決哪些問題，以及使用成本和潛在的風險，我將這些信息歸納爲「它怎麼樣」。

08 構建自驅動的「閉環」

不少人都知道閉環的概念，可是它的重要性和價值每每被低估。由於人老是短視的，「積少成多」之類的方式老是不受待見。

常規的搭建一個閉環的過程大可能是這樣的。

這裏所說的自驅動的「閉環」是這樣的。

如何才能變成這樣呢？只要作一件事，儘量多的對外輸出本身的知識。

舉個我本身的例子，我在2015年那會在項目中開始引入領域驅動設計，而且不斷的在內部進行分享它的好處，慢慢地愈來愈多的項目開始往這個方向走。

由於前期的不斷分享，因此在組織內部，別人對個人人設多了一個「DDD專家」的標籤，那麼你們遇到有關DDD的問題就會來和我一塊兒探討。

越到後面，我已經不用本身主動去尋找這個領域的知識去學習了，由於接收到的外部反饋已經足夠多了，它們可以倒逼我往前走。而且這些反饋都是實際的真實場景，此時的信息獲取和學習天然能達到「學以至用」的效果。

說實話，有很多人並非這麼想的，他們想的偏偏相反：「爲何每一個人都在問我問題！你本身去學習吧！」。

因此，當你遇到其餘人來請教你的時候，若是恰巧這是你所關注的領域，那麼應該去擁抱這個問題而不是排斥它。由於你是團隊裏最權威的人，這是你構建自驅動「閉環」的好機會。錯過這一回，下一回不知道得等多久。

前面文章裏說到，我會將「專業技能」、「鏈接外部的能力」、「領導力」三個維度組合起來給你看。就是下面這個樣子。

你會發現這裏麪包含了程序員在進階後的幾個常見崗位。

能夠對號入座一下：D

好了，咱們總結一下。

這篇我先和你聊了一下在你們眼中高級程序員是什麼樣子，發現沒有特別統一的標準，都是模糊的。這也體如今了幾個現實的場景中，好比招聘高級程序員、培養高級程序員上。

其次，我對初級、中級、高級程序員的特色分別闡述了本身的觀點。

而後，給出了一些幫助你們往高級程序員靠攏的實踐思路。

但願對你有所啓發。

最後，用Martin Fowler的一句話做爲結尾：「任何傻瓜都能寫計算機能理解的代碼，優秀的程序員編寫人類可以理解的代碼。」

Any fool can write code that a computer can understand. Good programmers write code that humans can understand

但願看到這篇文章的每一個程序員最終都能成爲頭髮茂盛的碼農：D

推薦文章：

• 8個月打磨，一份送給程序員的「分佈式系統」合集
• 一個引起程序員們幹架的問題

做者：Zachary

出處：https://zacharyfan.com/archives/934.html

---

若是你喜歡這篇文章，能夠點一下文末的「贊」。

這樣能夠給我一點反饋。: )

謝謝你的舉手之勞。

▶關於做者：張帆（Zachary， 我的微信號：Zachary-ZF）。堅持用心打磨每一篇高質量原創。歡迎 掃描下方的二維碼~。

若是你是初級程序員，想提高但不知道如何下手。又或者作程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關注個人公衆號「跨界架構師」，回覆「技術」，送你一份我長期收集和整理的思惟導圖。

若是你是運營，面對不斷變化的市場一籌莫展。又或者想了解主流的運營策略，以豐富本身的「倉庫」。歡迎關注個人公衆號「跨界架構師」，回覆「運營」，送你一份我長期收集和整理的思惟導圖。

按期發表原創內容：架構設計丨分佈式系統丨產品丨運營丨一些深度思考。