不想當將軍的兵不是一個好兵，不想成為技術骨干的技術人不是一名好技術。小菜的一個妹子如是說。
本文寫于 2019 年初，寫這篇文章之前，團隊每個小伙伴都給出了自己的答案，我挑幾個給大家曝光下：
觀點 1：有明確的職業規劃、持續學習和總結輸出；
觀點 2：獨立思考、消化吸收、深度鉆研、心態好、溝通好、會合作、有團隊精神；
觀點 3：技術難題攻堅、技術方案比對、學會管理資源項目與情緒、會溝通、有感染力；
觀點 4：做好視覺、把握視覺細節、擁抱業務、有擔當、敢冒險、心態好；
觀點 5：明確目標、心態開放、主動承擔責任、跳出舒適區、持續積累；
觀點 6：基礎夯實、經驗積累、學習能力、溝通協作、職業化、多看書。
不知道大家看完這些關鍵詞作何感想，隨便挑出幾個詞，大家可以摸著胸口問自己，做的足夠好么？是不是在很多方面自己都有堅持去做了，很多方面執行的也還不錯，比如多看書，比如主動承擔責任，沒有 10 分也有 7 分 8 分，但好像自己沒有成為心目中那個朦朦朧朧的技術骨干呢？
我曾經在 2018 年 7 月份把團隊的整體能力做了一次盤點，將它對比 2017 年 7 月份，一年前后團隊成員的成長速度，大家也可以參考制作這張圖（如果你是管理者建議每季度做一次），列出團隊所需要的技術棧等能力，然后逐項標記，星星越多代表能力越好，紅色的星星代表自己在 1 年內新 Get 到的和繼續沉淀的技能，整體排下來，不僅對自己的了解更直觀，對于自己在整個團隊中的位置也更了解：
而圖中，像小 ABCD 屬于是有一定工作經驗的員工，但 AD 也是團隊新人，為什么能成長這么快，每年會多出十幾顆星星，以及像小 EFHI 則是屬于職場新人，也能在一年時間內增長這么多技能點，我對所有人復盤后，發現所有人的成長路徑是不同的，但成長內核是類似的，我想這個內核是大家關心的，那我們就往下看吧。
技術骨干不會憑空產生
技術骨干的定義是相對的，這個相對的參考系橫軸是與同團隊同學比較，縱軸是基于當前公司業務的研發難度而言，前者與人的比較很殘酷也很主觀，工作年限的長短并不能決定一人是否是團隊的核心骨干。一個工作 6 年的人不一定是團隊的核心骨干，而一個工作 3 年的人有可能成為團隊技術的頂梁柱，而公司業務的研發難度則是一塊試金石，團隊有人搞不定但也有人總是能攻堅下來。
我們探討這個話題的背景是幾乎所有同學都希望自己成為技術骨干，而結果往往是只有部分人會在當下成為公司的技術骨干。事實上公司里是沒有技術骨干這么一個崗位職稱的，他往往存在于團隊 Leader 的心目中，也能間接通過職級反映。在大家的眼中，往往是那個沖刺在一線攻堅最難項目的人，我們既希望自己成為這個他，又畏懼自己承擔不起，自己也可能確實搞不定。這是一種變相的職場碾壓，話很糙，但在哪里不是如此這般呢？
高考的班級里，長跑的賽道上，甚至是同行業處于競爭狀態的幾家公司，大家的視線都是隨著領先者而移動，而領先者對于落后者的碾壓始終是一種現象。
對于現象，我們要中立觀察：領先就是領先，而碾壓無處不在。碾壓也一定會給自己帶來無形的壓力，也可能產生負面情緒。碾壓這個詞是非褒義甚至非中性的描述，我們應該關注的是領先的意義，碾壓的本質不在于它的含義，而是領先的意義，領先是任何一家公司，任何一個團隊，任何一個個體都希望發生的事情，如果把它定義成一段周期內的領先，這段領先就是我們所期待的奇跡。
而我們希望這個奇跡可以快速發生，持續發生，最好是發生在我所在的公司里，我所在的團隊里，或者發生在我自己身上。
再回到技術骨干這個詞，我們就清楚的看到，它是一段周期內一個人處于領先時的狀態，這個狀態是一種人設，有可能不會一直持續，也會被他人超越，但這個狀態一定不會憑空產生，因為領先的前提是，自己積累越來越多傲人的成績，而傲人的成績一定不是等出來而是拼出來的。
技術骨干身上的幾個特征
前面我們對技術骨干的存在合理性建立了一個認識，我們接下來看看在他/她身上會存在的幾個明顯特征：
技術底子扎實
萬丈高樓平地起，靠的就是深厚的地基，團隊楠哥語錄。
技術底子是工程師能力的核心基礎，技術棧語言棧的廣度深度，工程框架設計、原理的理解和運用的程度，這些方面不夠扎實基本上與技術骨干無緣了。
至于說廣度要多廣，深度要多深反而沒有一些清晰的指標。現在前端技術棧本身就是上下越來越厚，左右越來越寬，在 PC Web 的 Javascript 的單一技術棧上，如果積淀夠深也足以支撐一個骨干的長成，同樣在 ReactNative/Node 方面都如此，并不是前端的主要技術棧每一樣都逐一掌握的足夠好才能成為技術骨干，反倒是只要滿足一專多長，這一專成立甚至是多個擅長項成立，那么就具備成為技術骨干的實力硬件基礎了，接下來就要看軟件實力了。
小案例：團隊有個小伙伴 A，喜歡思考，關于 React 全家桶的知識儲備非常扎實，從框架設計到內部運行原理以及同類型數據流方案的優缺點，所有人與他交談都能有所收獲，甚至醍醐灌頂。
善于獨立解決難題
無論是在業務的技術架構中，還是純技術性的攻堅中，我們知道工程實現會遇到五花八門各種各樣的問題和難點，這些問題的解決和難點的突破，有許許多多可以嘗試的辦法，其中一個快捷鍵就是去請教團隊里更資深的人，也就是場外求助迅速解決，但一個技術骨干在這方面往往能獨立性的快速推進。
這里強調獨立性并不是說他也不去咨詢團隊內外的人，而是說他不依賴團隊內外的人，通過咨詢是給他提供更多分析問題的視角，最終的解決依然是靠他個人。
問題解決的過程也因人而異，有的會快速的 Github/StackOverflow/Google 甚至百度/搜狗微信參考和 review 各種開源實現，有人會直接進入框架代碼的閱讀和逐行 Debug，有人會拿一支筆在畫板上反復勾勒推理，無論哪一種，最終都是靠個人的能力解決問題，而每次解決問題后，能看到他征服困難后的成就感，用各種表情寫到了臉上，身邊的人也會受他感染共享征服感，大家可以設想下如果身邊好多個技術骨干，每天都連續上演征服成功的案例，這對于團隊士氣提升是非常有益的。
小案例：團隊有個小伙伴 B，喜歡獨辟蹊徑，無論多難受的問題到了他這里，總能獨立以異于常人的方式把問題解決掉，這種問題解決的越來越多，功力也日漸增長，每次解決完都要在團隊里炫耀吹噓一下自己多牛逼，所有人都跟著開心片刻，這種氛圍最終會影響到身邊人。
不畏懼陌生領域的挑戰
在一家增長型的公司，除了能感受到組織架構和業務上每個季度的變化外，還有一塊技術人最看重的東西，那就是業務進程內外潛在的巨大技術機會與挑戰，所謂技術成長空間。
這種機會通常是伴隨業務的快速發展和大膽試錯而來的，它有可能是業務驅動、運營驅動或者產品驅動，也有可能是技術驅動，無論哪種都可能會在原有的團隊技術棧里面炸開一個口子，這個口子可能就是所有團隊的工程師都不熟悉的領域，大家都不熟悉怎么辦，除了快速招人外，就必須有技術骨干頂上去硬啃，至少能支撐項目的 1.0 粗糙版跑出來。
那么這時候技術骨干身上的不畏懼等于什么？怎么才叫不畏懼？一句 “都閃開，老子來” 口號算不算，我覺得只能算一半，前一半是剛開始時的勇氣，另外一半是持續去挑戰所帶來的征服欲，征服欲越強或者興趣越濃，越有驅動力去想法設法鉆研，征服欲越弱，眼前的問題就會變成枯燥的任務，就算解決了，帶來的征服快感也隨之變弱。
小案例：團隊有個小伙伴 C，遇到的一個技術領域上黑盒，在我們團隊決定花精力去鉆研個初步方案后，小伙伴自費搞了必要的設備，甚至整個過年期間都在強攻技術難點，終于春節后，帶著可行性的方案來公司，為業務帶來了極大的想象空間，驅動他的不僅僅是任務，更是征服欲所帶來的滿足感。
極少讓別人失望
這個更多是在說結果，這個別人可能是合作方，可能是你的主管。為什么把這個單獨拎出來，是因為不是所有技術好的同學都具備這樣一個使命必達的執行力，只要允諾下來的事情，無論多難無論成敗，都能拿出一定的成果來讓等待的一方有所收獲，這是一個技術好的同學走向技術骨干最重要的一個特征之一。
技術骨干的同學技術一定好，但技術好的同學未必是技術骨干，這一點往往被忽視，也是童鞋們在工作中最容易想當然的一件事情，如果你讓別人失望的次數到了一定數量，那么距離技術骨干也還有一段距離了，因為骨干脫離了公司脫離了團隊就會失去實際意義。而一個團隊一定有它特定的定位和目標，目標的達成是衡量這個團隊戰斗力非常核心的標桿，也是主管腦海中的骨干的畫像特征，定義骨干與非骨干的分水嶺就在于此了。
如何快速成長為技術骨干
上面我們聊了技術骨干存在于我們大腦中的投影，也知道了他身上具備的顯著特征，那怎么成為技術骨干呢？可以從下面幾種路徑入手：
1. 弄清楚任務的 what 和 why
任何一個任務都有特定的背景和目的，比如老板讓你去預研下 Electron 開發客戶端軟件的可行性，這是一定要問清楚這個可行性的軟件客戶端開發方案是為了承載什么場景的需求？為什么要用客戶端而不是網頁的方式來實現？
這就是任務的 what 和 why，需要你跟老板明確對焦，有可能他需要的僅僅是一個可以收發消息的聊天功能實現方案，這時候一個 socket 的聊天室網頁版可能就能滿足需求，應該是去調研 socket 更有價值而非是 Electron。一旦真的是去調研了，即便調研過程很漂亮，但對于最終問題的解決不是最優解，損失的不僅僅是老板對你的信任，更是失去了一次獨立最優解拿下問題的機會。
有了這樣的一個任務的對焦過程，我們會更了解到自己做這件事情的價值，對于結果也會更有期待，原始的驅動力天然就存在了。
2. 從過程中而不是從結果中學習
在微信群和社區經常看到提問的同學，非常焦急的等待一個問題的答案，或者是自己獨立解決問題的過程中各種快捷方式求結果，拿到結果或答案后便迅速用到項目中，之后便丟到腦后，這是非常不可取的學習方式，每一次丟棄都喪失了一次成長的機會，要知道結果的價值是相對于業務和項目而言，而過程的價值才是相對于自己而言。
每一次拿到結果后，可以寫一篇博客記錄，也可以記個筆記，也可以弄張紙 review 一下，也可以講給別人聽，本質上是讓自己重新播放剛才解決問題的過程，從中觀察是什么樣有意無意的動作和思考方式，啟發了自己最終找到關鍵線索和路徑，這樣的一個思考過程反復錘煉會形成一個解決問題的套路庫，比如什么問題直接 Google 就可以，什么問題要深入到代碼中去深究，什么癥狀大概率是人為使用錯誤而非程序設計 Bug，從外向內再從內向外，讓自己不僅僅對于技術框架或方案的細節更了解，也對于它們宏觀上的特征更了解，最終讓自己的問題解決能力越來越高效。
3. 以開放的視角看待一切技術存在
如今互聯網所有上層的繁榮集市都是建立在各色各樣的技術底層之上，無論是從 ASP 到 Go 這樣的語言層面，還是 jQuery 到 React 這樣的框架層面，從硬件到軟件的方方面面雜糅在一個無限復雜的網絡中執行著自己 0 和 1 的信號邏輯，任何一只能抓老鼠的貓都是一只有用的貓，技術同樣如此，合理存在必然有特定場景下的價值，我們可以打開胸懷去觀察甚至去接納。
但開放到什么程度呢，是無限開放么？答案肯定不是。我們凡胎肉身不可能把目前極度細分的技術領域都摸過來，只能在特定的工程背景下做必要的心態開放，在未見到一個技術的真正價值之前不輕易否定它，在未評估好在自己項目中落地可能性之前不輕易使用它，這是兩個層面的接收和拒絕，前者是價值與合理性的接收，后者是可行性落地與成本評估的拒絕。
聊這么多，跟技術骨干有什么關系呢？是因為技術骨干永遠不知道自己接下來會面臨一個來自什么領域的挑戰，而保持視界的開闊和心態開放會給自己注入足夠多的信息線索，有選擇性的嘗鮮，保持試錯的好奇心，總是嘗試去琢磨一個技術方案的核心價值點和設計策略，這樣即便面臨陌生領域的挑戰，也可以用各種參照比對的方法為自己快速構建一個解決問題的路徑坐標系，在這個坐標系里面，上下左右延展總會碰到之前大腦中索引的一些信息線索，從而觸發一些靈感的產生，這些靈感的產生可能就是問題得到有效解決的關鍵。
4. 堅持高強度的學習和持續性的總結
當我們可以正確的認知一個任務的特征，也能有一個開放的心態和開闊的視野觀察問題，也能從問題解決過程中回收套路進行索引的時候，我們距離一個技術骨干就差一個習慣了，這個習慣就是高強度的學習和持續性總結的習慣，為什么學習要高強度，而總結要持續性呢？
學習是為了輸入，知識體系變得有力量一定需要足夠的輸入，而輸入從哪里來，連續做兩年 React 框架內的業務代碼可以帶來沉淀么？其實也未必，如果常年做業務但沒有深入框架內部學習，也沒有對框架之內的設計（如數據、狀態、交互、異步、更新等等實現原理）更沒有對框架之外的意義（組件、API、工具鏈、維護與封裝等成本與效率）有足夠的認識，那么所謂的內修基本功是站不住腳的。
至于說高強度，是因為低烈度的輸入會伴隨著遺忘，更會導致整個學習周期過長，更容易看不到質變而感覺枯燥無味甚至棄坑而去，這尤其在新人身上容易發生。如果讓我建議一個學習的周期，我覺得 1~2 個月的高強度學習，分成 2 ~ 4 個小階段是可取的，如果 2 個月沒有明顯進階，那么需要推倒重來從 0 開始，而不是續命。
伴隨著學習的一定是總結，所有的美食入口到胃，長長的腸道蠕動很久后，營養成分才能被機體充分吸收，最終再合成為新的動力之源要么燃燒要么存儲備用，這時候的攝入才轉成自己身體的一部分。無論是項目開發還是單純的學習，都要給自己建立一套 review 機制，通過 review 把自己攝入的零碎的知識點進行重組串聯，反反復復的理解消化，并重新輸入一套新的知識藍圖把它刻到自己的記憶硬盤中，通過這樣的持續性的總結歸納，自己的記憶硬盤會的不斷的升級調整，最終對于所有知識的理解會越來越立體。
小結
以上從準備、過程、心態和習慣上為新人設定了一個骨干長成的路徑，但真實的技術開發遠遠比這個復雜，需要再投入更多的心力精力幫自己邁過去一個個的天花板，所謂打怪升級再升級打怪，對于一個前端新人來說，在 2 ~ 4 年的工作過程中，最容易成長為技術骨干，而這段周期最好也有穩定的職場環境和社交環境，避免頻繁跳槽，避免受到太大干擾，把握住這段黃金期，隨后的技能大樹、職場之路會越長越健壯越走越寬闊。
Scott 近兩年無論是面試還是線下線上的技術分享，遇到許許多多前端同學，由于團隊原因，個人原因，職業成長，技術方向，甚至家庭等等原因，在理想國與現實之間，在放棄與堅守之間，搖擺不停，心酸硬扛，大家可以找我聊聊南聊聊北，對工程師的宿命有更多的了解，有更多的看見與聽見，Scott 微信：codingdream，也可以來關注 Scott 跟進我的動態[1]，本文未經許可不許轉載，獲得許可請聯系 Scott，否則在公眾號上直接轉載，尤其是裁剪內容后轉載，我都會直接進行投訴處理。
