程序員怎樣纔算是瞭解技術細節呢？

寫在前面

前一篇文章寫了程序員怎樣纔算是瞭解業務？後臺有人問那程序員怎樣算是瞭解技術了呢？技術過關須要瞭解技術細節嗎？

我以爲這個觀點也挺有意思能夠討論討論。

平時咱們也會私下討論這種問題，好比認爲某個高P技術通常啊，看PPT寫的大而全，可是好多技術細節都不知道，光知道名詞。

好比PPT裏面寫了在系統設計過程當中關注了緩存穿透，可是常見的緩存穿透方案也給不出來幾個，或者一討論到技術細節的時候就對方案自己上產生了模棱兩可的態度了，好比不知道布隆過濾器的使用方式。

討論到服務可用性保障，會說熔斷，降級，限流。可是聊到具體降級限流技術細節也含糊其辭，說只會用Hystrix搞。說不明白熔斷和降級具體有什麼區別。

有人認爲「技術人不能丟掉技術」，也有人認爲「工做作到上面都是考驗人性」，還有人認爲「工種不一樣，技術細節不清楚很正常」。

那技術細節須要瞭解到多細呢？或者什麼算是技術細節？對於一線開發人員，技術專家，架構師，系統負責人，技術總監來講技術細節有哪些呢？

那我就拋磚引玉聊聊個人想法，也許幾年後回過來在看個人觀點還比較膚淺吧。

須要瞭解技術細節嗎

以前一篇文章寫了我認爲面試過程當中考察面試者應該從技能，知識，方法論幾個角度考察，有的東西不懂並不表明面試者水平不行，輕易百度出來的東西也不必死記硬背。有些東西是須要真實場景來歷練的，好比經驗。有時要解決有些複雜的問題，沒有現成工具能夠利用，只能靠本身思考和分析，或者借鑑其它現成工具的原理，就離不開這些看不起的「細節知識」。

因此技術細節在作一線開發時很重要。因而咱們若是是應聘或者招聘一個核心骨幹一線研發工程師時，熱衷於在面試中考察候選人對細節的瞭解，若是不瞭解細節，這我的就很浮躁。一路梳理過去，各類細節瞭如指掌，全部的問題原形畢露，這樣工做才稱職，本身才放心。

可是隨着問題的複雜，職位的升高，瞭解技術或者說技術細節變成了「不可能的任務」——技術細節太多了，想要對每一個細節都瞭如指掌只會讓人疲憊不堪；技術人員也太多了，想要在每一個人那裏都保持權威也會讓人高度緊張。

慢慢發現，這已經不是一個用不用功、專不專心的問題，由於精力有限，要照顧的方面又太多，因此不管你多麼用功，多麼專心，都會感到力不從心，想找到在技術細節瞭如指掌，同時技術面較廣的面試者也變得愈來愈困難。

隨着負責的系統承受着千萬級訂單億級用戶量的訪問，自認爲本身在成長，身邊的人也在成長，可是發現沒有人能夠了解全部的細節。光看職級公司不少「大佬」無所不知、無所不曉，但仔細分析就發現，「大佬」每每只有在本身熟悉或者有充分準備的領域能夠談得很深，遇到本身不熟悉的領域，他們要麼不發聲，要麼用大而全或者不易出錯的話掩蓋過去了。

因此能夠說沒有人即瞭解技術細節，又在多個領域達到權威。

喜歡抓細節，喜歡就細節問題發表本身的見解。不論是在面試仍是在平時工做中，多半是營造本身的權威吧。形成的反作用每每是爲了考察細節，拔苗助長，錯過了很好的候選人。

若是是中高層管理者，本身的能力模型應該是隨時調整的，若是運維弱一點，就要在運維這個點上扎深一點；若是前端弱一點，就得在前端這個點上扎深一點；若是暫時各團隊情況都還不錯，那就把覆蓋面鋪更廣一點，多爲將來作規劃……

技術出身的技術領導者的優點是掌握基礎知識，對細節的瞭解，讓他們即使面對陌生領域，也可以迅速搭起「從已知到未知」的橋樑，迅速獲得「內行人」的視角，迅速和你們找到共同語言。非技術出身的領導者在這方面就要吃力許多，因此也只有少數極高明的人能作得好。

領導的關鍵就在於「找到合適的人，放到合適的位置上」，只有這樣，領導者的釘耙才能夠鋪得很寬，沒必要在具體的細節上耗費太多。可是，如何找到合適的人，如何放到合適的位置，這偏偏是須要有足夠的細節知識才能做出可靠判斷的。

哪些算是技術細節

技術細節的問題，大概能夠分爲三類：

第一類，號稱作過並深度參與的，也着重投入過精力的領域。這樣你應該對技術細節瞭如指掌，說出具體方案以外還須要你對你方案落地過程當中遇到的阻礙或者問題進行表達，系統的架構面對一個個問題進行解決才慢慢演進而來的。若是這個領域的細節答不出來，或者經不住追問，那多半是頗有問題的。

好比候選人說本身作過服務治理，那麼能談的不該當只是和流行的PPT同樣，大而化之地列舉服務治理的好處，幾個主要組成部分，還應當清楚服務註冊流程、服務生命週期定義、異常（尤爲是安全）狀況處理、擴縮容規範和限制等細節信息。若是談不出來，「作過服務治理」的經歷就應當打個折扣。

第二類，是在任何系統都須要使用的一些技術點，好比咱們都用java，jvm，多線程，各自鎖，併發編程相關，mysql原理及架構，高可用，高併發，高性能系統的經常使用體系和解決方案仍是須要知道的，系統要作複雜一點，在分析和設計的時候，這些知識是不能空缺的。

好比光在真空中的傳輸速度是30萬千米/秒，而在光纖中的傳輸速度是20萬千米/秒。這樣分析技術問題時纔有根據，好比北京到上海的直線距離大概是1200千米，因此單程理論傳輸時間大約要10ms，則ping值在25-30ms左右是正常的，沒有更多優化空間優化。但南京到上海的距離只有不到300千米，若是ping值也在30ms，則網絡上估計還有些問題。這樣的細節知識，就是前端、後端、運維均可以用上的（此處數據通過老高(高春輝)確認）。

第三類，是候選人沒有專門作過，但也不那麼基礎的細節。這類細節若是答不上來，其實並非很要緊。主要是考察候選人是否能夠就以前積累的知識或者方法論進行橫向遷移的學習能力，側面考察了技術的紮實程度。

後記

參考餘老師的觀點：

技術領導者的精力是有限的，能力模型既不該當是「博而不精」的寬泛，也不該當是「深而不廣」的專一，甚至業界流行的「T型人才」也不許確。對技術領導者來講，最合適的能力模型應當是釘耙型。

釘耙很寬，掃出去能夠覆蓋一個面；同時釘耙又有許多齒，能夠在某些具體的點上深刻。不過不管如何，太上老君只有那麼多神鑌鐵能夠用來打造九齒釘耙，在資源有限的狀況下就得具體分析，考慮釘耙到底有多寬，有幾個齒，每一個齒應該有多深。

技術領導者，最重要的是保持對技術的敬畏，以及不排斥談細節的意願，因此虛浮的做風是萬萬要不得的。但同時，也沒必要苛求本身時刻了解全部細節。

技術人要有足夠的技術素質，在寬度上能覆蓋這些領域，能找到靠譜的人、評估出靠譜的方案，或者在深度上能保持（通過一段時間的學習瞭解）介入能力，這些問題是多半都是能夠解決的。