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. 總結
總結一下，本文的觀點是：
- 技術細節學習難度不大，在需要深入的時候再深入了解最佳。
- 想要做成事，需要更宏觀的技術思維，是以專家漸漸變得眼光寬闊，格局很大。
- 專家擁有快速學習技術細節的能力，隻是這已不是其核心競争力，是以與其寫技術細節的文章，比如寫方法論的思考帶來的價值更大。
- 指引方向比走路更重要，專家都要逐漸成為引路人。
- 技術最終為業務服務，懂技術細節和讓業務先赢沒有必然的關系，是以在深入技術細節之前，要先了解業務，把握方向，防止技術細節出現路線問題。
讨論位址是：精讀《為什麼專家不再關心技術細節》 · Issue #153 · dt-fe/weekly
如果你想參與讨論，請 點選這裡，每周都有新的主題，周末或周一釋出。前端精讀 - 幫你篩選靠譜的内容。
關注 前端精讀微信公衆号
special Sponsors
- DevOps 全流程平台
版權聲明：自由轉載-非商用-非衍生-保持署名（創意共享 3.0 許可證）