新人成長：新人在前端團隊如何快速成長爲技術骨幹

著做權歸做者全部。商業轉載請聯繫 Scott 得到受權，非商業轉載請註明出處[務必保留全文，勿作刪減]。

不想當將軍的兵不是一個好兵，不想成爲技術骨幹的技術人不是一名好技術。小菜的一個妹子如是說。

本文寫於 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 跟進個人動態，本文未經許可不準轉載，得到許可請聯繫 Scott，不然在公衆號上直接轉載，尤爲是裁剪內容後轉載，我都會直接進行投訴處理。