題圖：from zoommy
關于這個話題，我曾經(jīng)寫過一篇「程序員真正的價值」，后來發(fā)表在了《跨越邊界》這本書里。最近 InfoQ 推送了一篇華仔的文章，就這個主題進行了更為深入的探討，不過，由于各種原因，這篇文章發(fā)表后很快刪掉了。很多讀者告訴我想看，于是重新發(fā)在 MacTalk 上，略做修改。
注：華仔是極客時間「從零開始學架構(gòu)」的專欄作者，李運華。他的專欄目前已經(jīng)有 17000 人在一起學習。
俗話說「文無第一，武無第二」，技術就是一種「文」的能力，很多時候我們很難直觀看出一個技術人員的實力，但不管是公司招聘的面試，還是公司內(nèi)部的晉升面評，都需要在較短時間內(nèi)快速判斷一個技術人員的實力。正因為技術實力評價本身沒有絕對客觀的標準，很多時候都會聽到類似的吐槽：
我們組內(nèi)的 XX 技術實力不如我，竟然他晉升通過了，我卻被刷掉了，評委真的是~！@#￥……
面試官問的都是什么鬼問題，我知道的基本沒問，我感覺他根本不會考察我的技術實力……
聽說算法和數(shù)據(jù)結(jié)構(gòu)最能體現(xiàn)程序員的實力，我要好好啃啃《算法導論》（然而啃完又忘記了）……
……
還有很多類似的問題和吐槽，背后都可以歸納為一個問題：當我們聊技術能力的時候，我們到底在聊什么？
有的人認為：技術實力就是指算法和數(shù)據(jù)結(jié)構(gòu)很厲害……
有的人認為：研究過Linux內(nèi)核源碼和看懂《深入淺出MFC》的才是技術牛逼的人……
有的人認為：會寫C 的才是真正的技術高手，因為C 的對象初始化有N種寫法……
有的人認為：技術高手必須對業(yè)務很熟悉……
有的人認為：貢獻了開源項目代碼的才是技術牛人……
有的人認為：只有架構(gòu)師才是技術大牛……
相信一千個人眼中有一千個哈姆雷特，一千個程序員心中有一千個技術大牛！
得益于工作崗位的關系，我在考核技術人員的實力時積累了較豐富的經(jīng)驗（包括踩坑的經(jīng)驗）。首先是招聘，前后面試了幾百個人吧，技術范圍包括服務器、android、iOS、前端，既包括初出茅廬的應屆生，也包括騰訊的T4大牛；其次是晉升評委，作為職業(yè)等級晉升的評委，面評過幾十個晉升的技術同學，各種案例都見過，也與其他評委一起互相交流，有時候甚至是針對某個同學通過還是不通過產(chǎn)生爭執(zhí)。通過這種不斷的實踐、思考、踩坑、交流的過程，逐步形成了一套完整的方法論，接下來就談談我的這套方法論，分享一下我是如何判斷技術人員的技術實力的。
簡單來說，判斷技術實力的一個總的原則就是：技術實力就是指解決問題的能力！
我們將這個原則細化一下，可以得到幾個細則：
1）不存在放之四海皆準的技術
簡單來說，問題是和領域相關的，技術是用來解決問題的，因此技術也是領域相關的，不存在放之四海皆準的技術。
有網(wǎng)友說：高斯林來做iOS開發(fā)，分分鐘秒殺現(xiàn)在所有的iOS開發(fā)人員，因為目前iOS經(jīng)驗最豐富的開發(fā)人員，經(jīng)驗也不過10年。我認為這是不可能的，iOS開發(fā)領域面臨的問題，和開發(fā)Java編程語言面臨的問題差異很大，當然，如果高斯林真的做上幾年iOS開發(fā)，確實可能超過很多iOS開發(fā)人員，但一開始就秒殺哪些做了7~8年的iOS程序員，這個是不可能的。
2）技術要能解決具體問題才有價值
技術只有能夠解決某個領域的問題才有價值，否則光知道某個技術沒什么用；掌握了某個技術但在當前的領域用不上，這個技術對當前領域來說也沒有價值。
當然，確實存在某些技術可能在當前看起來對當前領域沒有用，但后面可能會用到，因此技術人員需要自己儲備一些當前暫時沒有用的技術以拓寬技術視野，例如當前大火的人工智能和區(qū)塊鏈技術，但要注意「可能」這個詞，這需要技術人員自己進行判斷和平衡，不能拿技術儲備作為托詞一股腦的什么都儲備，例如數(shù)據(jù)庫開發(fā)工程師至少在這幾年是不需要儲備VR知識的。
3）問題的復雜度決定技術實力的高度
問題的復雜度不同，復雜度越高，解決起來越困難，相應的技術實力要求也越高。
我們拿這個原則去分析一下前面提到的各種技術實力的理解：
技術實力就是指算法和數(shù)據(jù)結(jié)構(gòu)很厲害
很多面試官喜歡讓面試者現(xiàn)場手寫冒泡排序、快速排序、鏈表之類的代碼，以此來判斷面試者的技術實力，但我們用這個原則去分析一下就可以發(fā)現(xiàn)，這樣并不能考核技術實力，假如招聘了一個會手寫快速排序的面試者，招進來后你會讓他用自己寫的快速排序解決什么問題？貌似絕大部分場景下都不可能讓一個新來的員工自己寫個快速排序來解決某個問題吧？
當然，肯定還是有人會說「我考核的是面試者的技術基礎和思維能力」，這個說法沒錯，但如果是這個目的，現(xiàn)場手寫快速排序這種面試方法就是錯誤的，如果是考察技術基礎，考核的范圍應該是算法的基本邏輯，優(yōu)缺點、適用場景，因為這些技術點在后續(xù)具體應用中選擇合適的算法來解決問題的時候很有用；如果是考察思維能力，考核的方式應該是給一個具體的算法應用題，來看看面試者的分析和思考過程，例如我在知乎上給了一道我們業(yè)務上曾經(jīng)用到的「如何快速計算你好友的好友和你的共同好友數(shù)」，沒想到引起了評論里面的大討論，有興趣的朋友也可以嘗試一下。
研究過Linux內(nèi)核源碼和看懂《深入淺出MFC》的才是技術牛逼的人
國內(nèi)技術人員（不知道國外是否類似）對于底層技術有一種偏見，認為只有懂底層才是真正的技術高手，否則都只是簡單的調(diào)用API完成功能。我當年也不例外，我曾經(jīng)說過「程序員的三個大坑：Linux內(nèi)核源碼、編譯原理（龍書）、深入淺出MFC」，我每個都跳過，而且還花費了大量時間卻收效甚微。其實用原則去分析一下就可以發(fā)現(xiàn)這個說法也站不住腳，如果我們從事Linux內(nèi)核開發(fā)，編程語言開發(fā)，MFC框架開發(fā)，這些技術確實能解決問題；但如果做得不是這些領域的開發(fā)，這些技術并不能幫我們解決什么問題，我還沒見過哪個Java編程的問題需要我去用編譯原理的技術去解決，也沒見過哪個數(shù)據(jù)庫的問題需要我去研究Linux內(nèi)核源碼才能解決，當然并不是說這些問題一定不存在，Java語言本身肯定也有bug，但這些問題是需要Java官方去解決，我們在應用中無需親自去解決，否則的話，效率會非常低，個人愛好無可厚非，但團隊必須考慮效率。
會寫C 的才是真正的技術高手，因為C 的對象初始化有N種寫法
這是程序員群體里面永恒的一個話題，哪個語言才是最好的最牛逼的，其中兩個著名的梗：PHP是世界上最好的語言，C 是世界上最牛逼的語言。C 確實語法復雜，功能強大，真正能完全掌握C 的程序員應該屈指可數(shù)，但這是否意味著掌握C 就牛逼了呢？并不盡然，我們拿原則來分析一下，如果用C 做游戲引擎，或者高性能中間件，C 確實能解決問題，但如果我們做的是android手機資訊app，C 能解決什么問題呢？自己寫個加密庫可能比系統(tǒng)帶的庫漏洞還多，自己用C 寫個SQLite好像沒什么意義。
架構(gòu)師才是技術大牛
架構(gòu)師幾乎是每個程序員的技術夢想，能夠成為架構(gòu)師（真正的架構(gòu)師，不是PPT架構(gòu)師），技術實力肯定很強，這點是沒有爭議的，但問題是當不上架構(gòu)師就不是技術大牛么？我們用原則來分析一下就會發(fā)現(xiàn)并不是這樣的，架構(gòu)師并不是全能的，他解決的主要問題是系統(tǒng)的結(jié)構(gòu)設計，還有一些問題是架構(gòu)師不能解決的，例如MySQL 5.6版本通過優(yōu)化一個false sharing問題，性能提升50%（ http://www.cis.upenn.edu/~delozier/docs/tmi_micro_2017.pdf ），這種問題點的發(fā)現(xiàn)和處理并不比架構(gòu)設計簡單，能發(fā)現(xiàn)和解決這個問題的技術人員實力非常高。
以上分析了幾個典型的誤區(qū)，其它的觀點，這里只貼一下簡單的答案，大家有興趣也可以套用這個原則去分析一下具體的原因，基本上八九不離十：
「技術高手必須對業(yè)務很熟悉」 —— 正確
「貢獻了開源項目代碼的才是技術牛人」—— 錯誤
理解評估技術實力的基本原則后，我們知道了需要解決的問題復雜度越高，技術實力就越高。在這個基礎上，我把技術實力分為兩大類6分類：
硬實力：真正解決問題的能力，別人可以看出來的能力，技術實力按照「點、線、面、體」的4個分類逐層上升；
軟實力：比硬實力更厲害但也更虛的能力，簡單來說，要想解決問題首先得發(fā)現(xiàn)問題，但很多時候問題并不是一目了然的，需要有一定的技術洞察力。軟實力主要包括2個核心能力：發(fā)現(xiàn)問題、技術創(chuàng)新
我把技術硬實力分為四個等級：點、線、面、體，技術等級依次提升，解決的問題復雜度也越來越高，下面詳細解釋一下。
【技術點】
「點」就是某個具體的技術，用來解決某個具體的問題，例如使用JDBC從數(shù)據(jù)庫讀取數(shù)據(jù)，目的是解決數(shù)據(jù)掉電丟失的問題；使用Java多線程，目的是為了解決大量用戶并發(fā)訪問的吞吐量和時延問題。
掌握了技術點，就可以開始基本的業(yè)務功能開發(fā)了。
【技術線】
「線」就是一系列相關的技術點組成，每個技術點都是為了解決某個問題。例如：
1）為了完成一個用戶請求，開發(fā)框架首先要有路由router功能，路由到具體Controller后，Controller進行業(yè)務邏輯處理，處理過程中可能會使用JDBC來讀取數(shù)據(jù)，訪問Redis讀取緩存等，這一連串的技術每個都解決了一個問題點，串起來就完成了一個業(yè)務功能的處理過程。
2）為了定位一個線上Java服務器響應慢的問題，需要用到tcpdump抓包，使用Java工具查看jvm的狀態(tài)，使用mysql命令行或者工具查看數(shù)據(jù)庫狀態(tài)，使用explain分析可疑SQL語句。
掌握了技術線，就可以完成某個業(yè)務功能的全流程設計和開發(fā)了。
【技術面】
「面」就是某一類相關技術線的綜合。例如：
1）Java開發(fā)是一個技術面，包括多線程、JDBC、文件讀寫、JVM調(diào)優(yōu)、JVM工具等多個技術線；
2）高性能開發(fā)是一個技術面，包括：數(shù)據(jù)庫分庫分表、緩存、多線程、HTTP優(yōu)化等；
3）數(shù)據(jù)庫維護是一個技術面，包括：數(shù)據(jù)庫調(diào)優(yōu)、數(shù)據(jù)庫問題定位、高性能數(shù)據(jù)庫表設計等；
掌握技術面，已經(jīng)是某個領域的專家了，簡單來說就是這個領域的問題找你都可以搞定。
【技術體】
「體」就是多個技術面的綜合。
最常見的「體」就是架構(gòu)設計，對于一個大型業(yè)務或者系統(tǒng)的架構(gòu)師來說，需要掌握多個技術面，然后進行設計和取舍。例如，一個后臺架構(gòu)師需要掌握Java的技術面、數(shù)據(jù)庫的技術面、網(wǎng)絡的技術面等，以及業(yè)務領域知識。
架構(gòu)設計是橫向技術面的綜合，我稱之為廣度技術體；還有一種縱向技術面的綜合，我稱之為深度技術體。例如Java的開發(fā)工程師，當達到技術面的水平時掌握了「多線程、JDBC、文件讀寫、JVM調(diào)優(yōu)、JVM工具等」，如果需要進一步在Java這個領域提升技術，就需要向下了解操作系統(tǒng)、硬件（CPU、內(nèi)存、磁盤等），從而更好的解決某些復雜的問題，例如Disruptor高性能并發(fā)框架的設計。
掌握了技術體，就可以進行架構(gòu)設計，或者成為某個領域的資深專家了，解決領域級的復雜問題。
軟實力包括發(fā)現(xiàn)問題和技術創(chuàng)新。
【發(fā)現(xiàn)問題】
有的問題很明顯，例如線上出故障，系統(tǒng)性能不達標，系統(tǒng)性能需要達到5W QPS；但有的問題并不那么明顯，并不能一眼看出是問題在哪里，是技術問題還是管理問題。
例如我們曾遇到團隊間協(xié)作開發(fā)效率很低，每次開發(fā)一個業(yè)務功能，都需要幾個系統(tǒng)的研發(fā)人員來討論接口協(xié)議、接口數(shù)據(jù)格式、接口安全加密、業(yè)務邏輯等，大家都不厭其煩，但好像又都必不可少，團隊間為了提高效率，項目經(jīng)理制定了規(guī)范、流程、模板等，但作用最終都不大。那后來是怎么解決的呢？通過引入服務中心來完成系統(tǒng)間同步接口調(diào)用，通過引入消息隊列來完成系統(tǒng)間異步消息通知，系統(tǒng)間協(xié)作效率大大提高，以前要開會討論幾個小時的事情，現(xiàn)在只要明確接口傳輸?shù)臄?shù)據(jù)內(nèi)容即可，甚至都不用開會，兩個研發(fā)一討論就差不多了。
除此以外，問題的根源往往掩蓋在很多問題表象之下，如果不解決根源問題，解決一個表象問題，獲得一時安寧，一段時間后又發(fā)生另外的問題，長此以往反反復復。
例如我們曾有個系統(tǒng)，今天交換機故障導致業(yè)務問題，明天系統(tǒng)bug導致業(yè)務問題，后天機柜斷電導致業(yè)務問題，還被黑客攻擊過，這些問題看起來都很獨立，問題的發(fā)生也感覺都是偶然的，按照出一個問題解決一個問題的方式也沒什么問題，但全年來看，業(yè)務就是出了很多問題，怎么解決？我們經(jīng)過分析，發(fā)現(xiàn)根本原因是業(yè)務需要異地多活，而架構(gòu)是雙機房單中心的，我們需要做到的不是避免每個問題的發(fā)生（事實上也不可能避免），而是應該做到問題發(fā)生后能夠快速處理，于是通過將架構(gòu)重構(gòu)為異地多活，重構(gòu)完成后還是有各種偶發(fā)問題發(fā)生，但對業(yè)務的影響就很小了。
發(fā)現(xiàn)問題的能力主要來源于經(jīng)驗，包括成功的經(jīng)驗、踩坑的經(jīng)驗、參考別人的經(jīng)驗，因此如果要培養(yǎng)自己這方面的能力，多思考、多總結(jié)、多學習、多參加行業(yè)交流。
【技術創(chuàng)新】
達到這個級別基本都是業(yè)界大神一般的級別，說實話我也沒什么經(jīng)驗，只能仰慕這些大神。
例如：
1）當年貝索斯要求亞馬遜公司內(nèi)的系統(tǒng)都服務化，后來是哪位大神想到可以把這個能力開放出來轉(zhuǎn)換為「云計算」？
2）阿里云王堅博士當年在眾人都不看好的情況下為何堅持云計算是未來？
3）Google在解決大數(shù)據(jù)問題時，如何能夠提煉出三篇論文，開啟了一個大數(shù)據(jù)時代？
一個面試者面試Java P7，其中有一項項目經(jīng)驗很牛逼：XX架構(gòu)重構(gòu)，性能提升10倍。于是，我針對這個項目經(jīng)驗進行了深入的考察，結(jié)果……
下面是我們大概的對話過程：
我：請簡單介紹一下這個項目重構(gòu)。
面：我們某個業(yè)務和運動會有關，每次關鍵比賽前業(yè)務訪問量是平時的10倍以上，原來的系統(tǒng)量一大就卡死了，用戶體驗很不好，需要重構(gòu)。
我：具體怎么做的呢？
面：我通過引入mc緩存，將原來直接訪問數(shù)據(jù)庫的操作改為先訪問緩存，性能比原來提升了10倍。
我：為何你想到了引入mc？
面：（卡了一下，有點驚訝我的問題）……我上網(wǎng)查了一下資料，很多都說mc能夠大幅提升性能，并且使用后確實效果很好。
[點評1]這是典型的「代碼靠抄，方案靠搜，效果靠試」，面試者看到了一個問題，但沒有分析和思考，然后上網(wǎng)搜方案，看到了好像很多人都說引入mc都能解決問題，關鍵是最終確實好像解決了，這讓面試者自我感覺良好。
我：mc能大幅提升性能的原理是什么？
面：緩存訪問快，數(shù)據(jù)庫訪問慢。
我：那mc性能多高，數(shù)據(jù)庫性能多高？
面：……（想了10秒）抱歉，沒有研究過。
[點評2]這是典型的知其然不知其所以然，開源方案拿來就用，基本的測試和原理研究都沒做過。
我：沒關系，那我們換個問題，重構(gòu)后你們的系統(tǒng)用到的機器數(shù)量是多少？相比重構(gòu)前減少了多少？
面：機器數(shù)量是100臺，相比重構(gòu)前沒有減少。
我：哦，100臺機器，QPS每臺才300多，我看你們的業(yè)務也不是很復雜，為何這么低？
面：……（卡住10秒）這……300多QPS好像也不低吧？
我：那你有沒有分析過每次請求全流程每個階段的性能耗時？瓶頸在哪里？
面：（卡住5秒）沒有分析過呢？
我：那為何就認定引入mc就有效果？
面：……（卡住10秒）我看大家都說引入緩存能大幅提升性能，而且最終效果確實很好。
[點評3]這就是知道技術點，不知道技術線和技術面，按道理對于系統(tǒng)性能問題的分析，至少是技術線級別的，需要分析每個請求每個階段的耗時和原因；也可以是技術面級別的，例如分析數(shù)據(jù)庫的設計、服務器的負載均衡等，還可以是技術體級別的，例如架構(gòu)是否合理，是否可以將某個子系統(tǒng)拆分，引入消息隊列等。
我：好吧，換個問題，如果讓你再一次優(yōu)化系統(tǒng)，你覺得可以怎么做？
面：……（思考20秒）我覺得目前的系統(tǒng)性能已經(jīng)足夠，應該不需要優(yōu)化了。
[點評]考察的是發(fā)現(xiàn)問題的能力，但他發(fā)現(xiàn)不了問題，其實前面已經(jīng)都提到了，100臺機器就是問題，QPS過低也是問題，但由于他沒有經(jīng)驗，是看不出這些問題的。
很遺憾，最終這個面試者沒有通過面試。
