1. 引言
本週的精讀是有感而發。
筆者接觸前端已有八年，觀察了不少前端大牛的發展路徑，發現成功的人都具有相似的經歷：
初期技術熱情極大 -> 大量標誌性技術專案 -> 轉向綜合性思考 -> 帶團隊/關注方法論
也就是專家們變得越來越不關心技術細節。需要說明是的，這裡說的專家不再關心細節，不代表成為專家後學不會細節，也不代表專家不瞭解細節。
早期挺難理解這種轉變的，筆者在學校裡的知名度來自於前端做得精深，一根筋鑽研技術的人眼裡是容不下沙子的，所以當初為一些前輩轉到管理特別不理解，認為他們背叛了前端。
不過筆者的觀念也在逐漸發生轉變，漸漸自己也在朝著當初反感的方向發展，覺得這一定不是偶然，所以就整理了一下感悟，希望可以證明這個發展路徑的必然性。
2. 精讀
首先我們要明確技術員與科學家的區別，為業務提供技術支援都是技術員，所以前端是一門技術，不是科學。
另外，技術的發展需要商業推動，沒有使用場景的國家是很難推動技術進步的，科學除外。
所以業務技術是具備可持續發展的路線，畢竟大家都要吃飯，有業務價值的專案會活下來，附著在業務上的技術才能活下來，才有可能開枝散葉。
本文將從三個點去解釋，為什麼專家看上去越來越原理技術細節。
2.1 技術細節對個人的重要性是在變化的
隨著工作年限增加，技術細節重要性在慢慢降低，反之技術視野重要性在慢慢增加。
在找工作初期，技術細節是重要的敲門磚
大學畢業的那段時間，技術細節是一塊重要的敲門磚，只有掌握好技術，才會有公司願意要你。
這也是為什麼說畢業生不要一進公司就談戰略，因為時機不對。
技術不是科學，普通人下功夫可以學會
學習技術不需要很聰明的頭腦，只要肯下功夫，擁有不錯的理解能力，任何人都可以把技術細節搞清楚。
也就是學習技術細節是沒有技術門檻，隨著年齡的增加，如果只累積了大家都能學會的內容，那麼當舊知識被淘汰後，學習新知識的速度又不如年輕人快，會逐漸失去經驗優勢。
那麼如何利用無門檻的特徵，將其變為門檻呢？那就是任何年齡段學習技術細節都很容易，在你需要深入細節的時候再深入進去，不需要深入的時候把時間花在瞭解巨集觀架構上。
就是培養高效的學習能力，能準確判斷某個技術細節是否有必要掌握，如需要該如何快速掌握核心內容，並在掌握之後不留戀，可以快速抽身出來繼續全域性性思考。這種思維是有門檻的，技術專家都可以做到這一點。
做成事不一定要搞懂細節
乍一看有點匪夷所思：不瞭解細節怎麼能做成事？
雖然理解技術細節可以做成事，但做成事不一定需要理解業務細節。
這要看怎麼理解業務與技術的關係，比如建設 “資料聯邦”，光是瞭解各個不同的儲存系統技術細節可能就要花很久，而實際上是沒必要將所有技術細節都弄懂的，只要定好一個通用互動規範，各儲存系統各自封裝一套符合這個規範的互動介面即可。
做成事往往需要巨集觀的技術思維，需要將許多技術點連結在一起。舉個例子，做成事就類似於軍官指揮作戰，做成的目的是通過制定打法贏得戰爭，而不是自己衝鋒陷陣並測量敵人壕溝的寬度。關心技術細節只最終落實到每個人具體實施項中的一部分，技術細節的目標累加起來才是做成事。
2.2 搞清楚業務對技術的真實訴求
業務期望通過技術實現功能，所以技術專家要做的是如何更好的實現業務需求，這就意味著理解業務需求是第一重要的能力。試想一個不能理解業務要做什麼的人，即便懂得再多技術細節，對業務也是沒有價值的。
業務思維是解決問題，技術思維是創造問題
擁有技術思維的人，容易沉迷於解決不切實際的問題，或者是別人解決過的問題。這種思維對技術學習是非常有幫助的，但如果長期不能轉變這種思維，對公司來說是無法創造什麼價值的。
擁有業務思維的人，首先要懂業務，只有懂業務，跟著對的業務，才能對未來又信心，知道自己的付出可以換來回報。
懂業務後，才知道如何通過技術幫助業務獲得成功。
比如在一家創業公司，老闆的眼光很準，進入的時機較早，市場是一片藍海。你通過分析後，發現要幫助業務佔領市場，只要利用某個成熟技術框架快速迭代，就可以在短期幫助業務贏得市場。但是這個框架定製能力不強，如果新需求來了可能需要花時間重構掉。此時技術思維的人只會考慮程式碼維護性，提出自研一套框架，而擁有業務思維的技術專家會決定先用成熟的技術快速作出原型，等業務穩定後再重構掉。
當然現在網際網路市場競爭很激烈，低技術門檻的藍海基本已都變成了紅海，上面提到的場景可能比較少見，我們更多需要決策的是未來幾年內業務的收益是否值得現在投入的研發資源。
兩個會寫框架的人，不如一個能決策的人
另一個簡單的例子就是，假如技術專家只會一頭紮在技術細節裡，對各種前端框架的實現瞭如指掌，大家都能造出優雅、易用、可維護，而且還帶有各自 “特色優勢” 的框架或者輪子，那麼團隊很容易陷入兩個專家屁股決定腦袋的技術紛爭中。這種情況下，兩名技術專家的產出甚至不如一個實習生大，畢竟實習生直接拿來開源框架上手，99% 的情況可靠性比前端專家自己造的輪子更好。
從另一個方面來說，現階段前端界能寫出 React、Vue 框架的人太多了，已經寫出來的類 React、Vue 的框架也數不過來。去掉為了練手而做的專案，真正希望推廣出去給別人用的還佔絕大多數，這是開源界典型的問題：重複低水平造輪子不需要理由，推廣給你用也不需要負責任。由於框架屬於網際網路虛擬資產，邊界成本為零，這決定了框架市場一定是個大寡頭市場，不可能有類似的專案通過一些不痛不癢的特色分一杯羹。那麼就算招 10 個會寫框架的人進入公司架構組，最後只有兩種可能：要麼架構臃腫，每個人都把自己的一部分功勞加入進去；要麼就是選擇一個更不好的方案，這樣不會損害任何一位架構師的利益。
所以現在公司更傾向於內部培養人才，因為內部的人瞭解業務需要什麼，創造的價值往往比空降的架構師更大。
寬廣的技術視野更容易借力
現在技術點越來越多，如果什麼技術細節都要詳細瞭解，最終一定不能有很好的全域性視野。比較好的狀態是找幾個重點深入瞭解，其他的技術點在掌握了全域性技術視野後再考慮深入。
在網際網路初期，很多技術框架還不完善時，技術借力的意義不大，畢竟也沒有多少東西可用。
但是現在無論前端還是後端的技術、輪子已經眼花繚亂了，能掌握這些已有技術的人，價值已經逐漸大於會完整了解某些技術細節的人。一個優秀的專家應該能快速定位要解決的業務問題是否有成熟的技術方案，如何以最小的投入產出比實現，同時保持良好的維護性應變業務維護。
2.3 僅僅技術好是無法成為專家的
技術專家真的代表技術壁壘很強的人嗎？是的，但只有技術能力是不夠的。
為什麼開源專案後期要尋找協作者？
我做開源專案的初期，所有框架和原始碼都事必躬親，覺得自己有更好的點子可以勝過其他框架。初期很少有貢獻者參與，當然我也不願意其他貢獻者參與，畢竟他們不瞭解設計理念，只有我自己的修改可以讓我滿意。
還有誰比作者更瞭解他的開源專案呢？那為什麼一個大型開源專案運作到後期，基本都是協作者在維護？
因為開源是一件系統化的事情，如果你想長期維護他，必須建立好文件系統，讓你的思路可複製，讓他人可參與。如果開源專案只有你一個人懂，那麼同時維護兩個、四個、六個的時候，你定會發現力不從心。
至於一些開源大神一人維護幾百甚至上千 Repo，背後一定有更多的貢獻者支援，一個人就算辭職在家專職做開源，也很難同時維護超過 10 個開源專案。你需要擁有開放的心態讓更多人加入進來，將成就感和榮譽感分一些給貢獻者，他們才會持續為專案貢獻。
能夠呼叫資源才能成為專家
開源界就是專案搶佔關注度的遊戲。假設開源社群總人數為 100，你的專案能夠吸引到 10 個人瀏覽，5 個人使用，2 個人貢獻，基本就能存活下來。而開源社群至少有 100 個專案，社群總人數不足以支援每一個專案，只有獲得足夠關注度的專案才能保持長青。
公司內也是如此，專家級以上的 Title 會要求協作能力，可以調動身邊甚至其他部門資源的人才能在公司發揮更大的價值。
CEO 通過頂層設計調動了全公司資源，而業務線總裁通過任務拆解調動了整個業務線的人，通過層層目標拆解，並保證每一層都能充分調動下一層所有資源，公司才能高效的運轉。
如果一直關心技術細節，你永遠是一個孤立節點，在任何維度的組織中都是最底層，就算 24 小時不睡覺，也最多算兩個人力資源。想要突破一天 24 小時的限制，就要花時間讓別人認同你的設計，並朝著一個方向努力，你的節點才能上移，但隨之而來的是承擔更多風險，比如分配給別人的任務給弄砸了，為公司帶來了不良影響，那麼負責人就要背鍋。
3. 總結
總結一下，本文的觀點是：
- 技術細節學習難度不大，在需要深入的時候再深入瞭解最佳。
- 想要做成事，需要更巨集觀的技術思維，所以專家漸漸變得眼光寬闊，格局很大。
- 專家擁有快速學習技術細節的能力，只是這已不是其核心競爭力，所以與其寫技術細節的文章，比如寫方法論的思考帶來的價值更大。
- 指引方向比走路更重要，專家都要逐漸成為引路人。
- 技術最終為業務服務，懂技術細節和讓業務先贏沒有必然的關係，所以在深入技術細節之前，要先理解業務，把握方向，防止技術細節出現路線問題。
如果你想參與討論，請 點選這裡，每週都有新的主題，週末或週一釋出。前端精讀 - 幫你篩選靠譜的內容。
關注 前端精讀微信公眾號
special Sponsors
版權宣告：自由轉載-非商用-非衍生-保持署名（創意共享 3.0 許可證）