精讀《爲何專家再也不關心技術細節》

時間 2019-12-05

標籤精讀爲何專家再也不關心技術細節简体版

原文原文鏈接

1. 引言

本週的精讀是有感而發。前端

筆者接觸前端已有八年，觀察了很多前端大牛的發展路徑，發現成功的人都具備類似的經歷：git

初期技術熱情極大 -> 大量標誌性技術項目 -> 轉向綜合性思考 -> 帶團隊/關注方法論github

也就是專家們變得愈來愈不關心技術細節。須要說明是的，這裏說的專家再也不關心細節，不表明成爲專家後學不會細節，也不表明專家不瞭解細節。後端

早期挺難理解這種轉變的，筆者在學校裏的知名度來自於前端作得精深，一根筋鑽研技術的人眼裏是容不下沙子的，因此當初爲一些前輩轉到管理特別不理解，認爲他們背叛了前端。前端框架

不過筆者的觀念也在逐漸發生轉變，漸漸本身也在朝着當初反感的方向發展，以爲這必定不是偶然，因此就整理了一下感悟，但願能夠證實這個發展路徑的必然性。微信

2. 精讀

首先咱們要明確技術員與科學家的區別，爲業務提供技術支持都是技術員，因此前端是一門技術，不是科學。架構

另外，技術的發展須要商業推進，沒有使用場景的國家是很難推進技術進步的，科學除外。框架

因此業務技術是具有可持續發展的路線，畢竟你們都要吃飯，有業務價值的項目會活下來，附着在業務上的技術才能活下來，纔有可能開枝散葉。學習

本文將從三個點去解釋，爲何專家看上去愈來愈原理技術細節。.net

2.1 技術細節對我的的重要性是在變化的

隨着工做年限增長，技術細節重要性在慢慢下降，反之技術視野重要性在慢慢增長。

在找工做初期，技術細節是重要的敲門磚

大學畢業的那段時間，技術細節是一塊重要的敲門磚，只有掌握好技術，纔會有公司願意要你。

這也是爲何說畢業生不要一進公司就談戰略，由於時機不對。

技術不是科學，普通人下功夫能夠學會

學習技術不須要很聰明的頭腦，只要肯下功夫，擁有不錯的理解能力，任何人均可以把技術細節搞清楚。

也就是學習技術細節是沒有技術門檻，隨着年齡的增長，若是隻累積了你們都能學會的內容，那麼當舊知識被淘汰後，學習新知識的速度又不如年輕人快，會逐漸失去經驗優點。

那麼如何利用無門檻的特徵，將其變爲門檻呢？那就是任何年齡段學習技術細節都很容易，在你須要深刻細節的時候再深刻進去，不須要深刻的時候把時間花在瞭解宏觀架構上。

就是培養高效的學習能力，能準確判斷某個技術細節是否有必要掌握，如須要該如何快速掌握核心內容，並在掌握以後不留戀，能夠快速抽身出來繼續全局性思考。這種思惟是有門檻的，技術專家均可以作到這一點。

作成事不必定要搞懂細節

乍一看有點匪夷所思：不瞭解細節怎麼能作成事？

雖然理解技術細節能夠作成事，但作成事不必定須要理解業務細節。

這要看怎麼理解業務與技術的關係，好比建設「數據聯邦」，光是瞭解各個不一樣的存儲系統技術細節可能就要花好久，而其實是不必將全部技術細節都弄懂的，只要定好一個通用交互規範，各存儲系統各自封裝一套符合這個規範的交互接口便可。

作成事每每須要宏觀的技術思惟，須要將許多技術點連接在一塊兒。舉個例子，作成事就相似於軍官指揮做戰，作成的目的是經過制定打法贏得戰爭，而不是本身衝鋒陷陣並測量敵人壕溝的寬度。關心技術細節只最終落實到每一個人具體實施項中的一部分，技術細節的目標累加起來纔是作成事。

2.2 搞清楚業務對技術的真實訴求

業務指望經過技術實現功能，因此技術專家要作的是如何更好的實現業務需求，這就意味着理解業務需求是第一重要的能力。試想一個不能理解業務要作什麼的人，即使懂得再多技術細節，對業務也是沒有價值的。

業務思惟是解決問題，技術思惟是創造問題

擁有技術思惟的人，容易沉迷於解決不切實際的問題，或者是別人解決過的問題。這種思惟對技術學習是很是有幫助的，但若是長期不能轉變這種思惟，對公司來講是沒法創造什麼價值的。

擁有業務思惟的人，首先要懂業務，只有懂業務，跟着對的業務，才能對將來又信心，知道本身的付出能夠換來回報。

懂業務後，才知道如何經過技術幫助業務得到成功。

好比在一家創業公司，老闆的眼光很準，進入的時機較早，市場是一片藍海。你經過分析後，發現要幫助業務佔領市場，只要利用某個成熟技術框架快速迭代，就能夠在短時間幫助業務贏得市場。可是這個框架定製能力不強，若是新需求來了可能須要花時間重構掉。此時技術思惟的人只會考慮代碼維護性，提出自研一套框架，而擁有業務思惟的技術專家會決定先用成熟的技術快速做出原型，等業務穩定後再重構掉。

固然如今互聯網市場競爭很激烈，低技術門檻的藍海基本已都變成了紅海，上面提到的場景可能比較少見，咱們更多須要決策的是將來幾年內業務的收益是否值得如今投入的研發資源。

兩個會寫框架的人，不如一個能決策的人

另外一個簡單的例子就是，假如技術專家只會一頭紮在技術細節裏，對各類前端框架的實現瞭如指掌，你們都能造出優雅、易用、可維護，並且還帶有各自「特點優點」的框架或者輪子，那麼團隊很容易陷入兩個專家屁股決定腦殼的技術紛爭中。這種狀況下，兩名技術專家的產出甚至不如一個實習生大，畢竟實習生直接拿來開源框架上手，99% 的狀況可靠性比前端專家本身造的輪子更好。

從另外一個方面來講，現階段前端界能寫出 React、Vue 框架的人太多了，已經寫出來的類 React、Vue 的框架也數不過來。去掉爲了練手而作的項目，真正但願推廣出去給別人用的還佔絕大多數，這是開源界典型的問題：重複低水平造輪子不須要理由，推廣給你用也不須要負責任。因爲框架屬於互聯網虛擬資產，邊界成本爲零，這決定了框架市場必定是個大寡頭市場，不可能有相似的項目經過一些不痛不癢的特點分一杯羹。那麼就算招 10 個會寫框架的人進入公司架構組，最後只有兩種可能：要麼架構臃腫，每一個人都把本身的一部分功勞加入進去；要麼就是選擇一個更很差的方案，這樣不會損害任何一位架構師的利益。

因此如今公司更傾向於內部培養人才，由於內部的人瞭解業務須要什麼，創造的價值每每比空降的架構師更大。

寬廣的技術視野更容易借力

如今技術點愈來愈多，若是什麼技術細節都要詳細瞭解，最終必定不能有很好的全局視野。比較好的狀態是找幾個重點深刻了解，其餘的技術點在掌握了全局技術視野後再考慮深刻。

在互聯網初期，不少技術框架還不完善時，技術借力的意義不大，畢竟也沒有多少東西可用。

可是如今不管前端仍是後端的技術、輪子已經眼花繚亂了，能掌握這些已有技術的人，價值已經逐漸大於會完整了解某些技術細節的人。一個優秀的專家應該能快速定位要解決的業務問題是否有成熟的技術方案，如何以最小的投入產出比實現，同時保持良好的維護性應變業務維護。

2.3 僅僅技術好是沒法成爲專家的

技術專家真的表明技術壁壘很強的人嗎？是的，但只有技術能力是不夠的。

爲何開源項目後期要尋找協做者？

我作開源項目的初期，全部框架和源碼都事必躬親，以爲本身有更好的點子能夠賽過其餘框架。初期不多有貢獻者參與，固然我也不肯意其餘貢獻者參與，畢竟他們不瞭解設計理念，只有我本身的修改可讓我滿意。

還有誰比做者更瞭解他的開源項目呢？那爲何一個大型開源項目運做到後期，基本都是協做者在維護？

由於開源是一件系統化的事情，若是你想長期維護他，必須創建好文檔系統，讓你的思路可複製，讓他人可參與。若是開源項目只有你一我的懂，那麼同時維護兩個、四個、六個的時候，你定會發現力不從心。

至於一些開源大神一人維護幾百甚至上千 Repo，背後必定有更多的貢獻者支持，一我的就算辭職在家專職作開源，也很難同時維護超過 10 個開源項目。你須要擁有開放的心態讓更多人加入進來，將成就感和榮譽感分一些給貢獻者，他們纔會持續爲項目貢獻。

可以調用資源才能成爲專家

開源界就是項目搶佔關注度的遊戲。假設開源社區總人數爲 100，你的項目可以吸引到 10 我的瀏覽，5 我的使用，2 我的貢獻，基本就能存活下來。而開源社區至少有 100 個項目，社區總人數不足以支持每個項目，只有得到足夠關注度的項目才能保持長青。

公司內也是如此，專家級以上的 Title 會要求協做能力，能夠調動身邊甚至其餘部門資源的人才能在公司發揮更大的價值。

CEO 經過頂層設計調動了全公司資源，而業務線總裁經過任務拆解調動了整個業務線的人，經過層層目標拆解，並保證每一層都能充分調動下一層全部資源，公司才能高效的運轉。

若是一直關心技術細節，你永遠是一個孤立節點，在任何維度的組織中都是最底層，就算 24 小時不睡覺，也最多算兩我的力資源。想要突破一天 24 小時的限制，就要花時間讓別人認同你的設計，並朝着一個方向努力，你的節點才能上移，但隨之而來的是承擔更多風險，好比分配給別人的任務給弄砸了，爲公司帶來了不良影響，那麼負責人就要背鍋。