資訊專欄INFORMATION COLUMN
摘要：需要說明是的，這里說的專家不再關心細節，不代表成為專家后學不會細節，也不代表專家不了解細節。本文將從三個點去解釋，為什么專家看上去越來越原理技術細節。試想一個不能理解業務要做什么的人，即便懂得再多技術細節，對業務也是沒有價值的。
1. 引言
本周的精讀是有感而發。
筆者接觸前端已有八年，觀察了不少前端大牛的發展路徑，發現成功的人都具有相似的經歷：
初期技術熱情極大 -> 大量標志性技術項目 -> 轉向綜合性思考 -> 帶團隊/關注方法論
也就是專家們變得越來越不關心技術細節。需要說明是的，這里說的專家不再關心細節，不代表成為專家后學不會細節，也不代表專家不了解細節。
早期挺難理解這種轉變的，筆者在學校里的知名度來自于前端做得精深，一根筋鉆研技術的人眼里是容不下沙子的，所以當初為一些前輩轉到管理特別不理解，認為他們背叛了前端。
不過筆者的觀念也在逐漸發生轉變，漸漸自己也在朝著當初反感的方向發展，覺得這一定不是偶然，所以就整理了一下感悟，希望可以證明這個發展路徑的必然性。
2. 精讀
Warn：本文所說的技術專家，僅針對研究上層技術的專家，不包括底層技術專家。 在 Google 底層專家人數極少，大部分專家都要走業務技術的路線。
首先我們要明確技術員與科學家的區別，為業務提供技術支持都是技術員，所以前端是一門技術，不是科學。
另外，技術的發展需要商業推動，沒有使用場景的國家是很難推動技術進步的，科學除外。
所以業務技術是具備可持續發展的路線，畢竟大家都要吃飯，有業務價值的項目會活下來，附著在業務上的技術才能活下來，才有可能開枝散葉。
本文將從三個點去解釋，為什么專家看上去越來越原理技術細節。
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 許可證）
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/6637.html
摘要：前端框架總是帶入后端思維，而則是把前端思維帶入了后端運維。前端同學對應該尤為激動。而帶來了進一步優化的空間。當服務器面臨攻擊重啟磁盤故障時，打開復雜的工作臺或登陸后一通操作才能恢復。 1. 引言 Serverless 是一種 無服務器架構，讓用戶無需關心程序運行環境、資源及數量，只要將精力 Focus 到業務邏輯上的技術。 現在公司已經實現 DevOps 化，正在向 Serverles...
摘要：大公司廣泛使用的開源庫，并且有一定國際影響力，而且大廠也有成功開源歷史經驗的話，就會增加說服力。總結下次技術選型討論時，可以拿出規則一條一條比對了然后技術選型只是基礎庫，利用這些基礎可以維護好自己的開源庫，把更多時間用在創造業務價值上。 1 引言 作者給出了從 12 個角度全面分析 JS 庫的可用性，分別是： 特性。 穩定性。 性能。 包生態。 社區。 學習曲線。 文檔。 工具。 發...
摘要：解析可以分為如下四步詞法分析，將字符串拆分成包含關鍵詞識別的字符段。涉及到語意處理就要考慮上下文，而這都不是詞法分析階段要考慮的。更多討論討論地址是精讀手寫編譯器詞法分析如果你想參與討論，請點擊這里，每周都有新的主題，周末或周一發布。 1 引言 因為工作關系，需要開發支持眾多方言的 SQL 編輯器，所以復習了一下編譯原理相關知識。 相比編譯原理專家，我們只需要了解部分編譯原理即可實現 ...
摘要：精讀前端可以從多個角度理解，比如規范框架語言社區場景以及整條研發鏈路。同是前端未來展望，不同的文章側重的格局不同，兩個標題相同的文章內容可能大相徑庭。作為使用者，現在和未來的主流可能都是微軟系，畢竟微軟在操作系統方面人才儲備和經驗積累很多。 1. 引言 前端展望的文章越來越不好寫了，隨著前端發展的深入，需要擁有非常寬廣的視野與格局才能看清前端的未來。 筆者根據自身經驗，結合下面幾篇文章...
摘要：引言本周精讀的文章是。精讀總的來說，雖然拆分子倉庫拆分子包是進行項目隔離的天然方案，但當倉庫內容出現關聯時，沒有任何一種調試方式比源碼放在一起更高效。前端精讀幫你篩選靠譜的內容。 1. 引言 本周精讀的文章是 The many Benefits of Using a Monorepo。 現在介紹 Monorepo 的文章很多，可以分為如下幾類：直接介紹 Lerna API 的；介紹如何...
閱讀 2351·2021-11-24 11:16
閱讀 2038·2021-09-30 09:47
閱讀 2006·2021-09-10 10:51
閱讀 1323·2019-08-30 14:08
閱讀 3141·2019-08-30 13:47
閱讀 1528·2019-08-30 13:02
閱讀 3233·2019-08-29 12:29
閱讀 3198·2019-08-26 17:05
