前言
自 15 年 9 月第一次接觸前端開發(fā)到現在已經過去了五年多，最開始是從一個很小的外包團隊團隊出身，沒有帶，沒人管，幾乎一個人干了 2 年多的活。
做了接近 3 年的組長，碰巧近期團隊在調整，今年也經歷了很多事情，回想一下自己這一路倒也挺有感觸。
雖然我不是一個很好的組長，但也見過不少五年工作三年經驗情況的同學，他們在遇到瓶頸期時候的迷茫與無措。
畢竟自己算過來人，寫一下對初級前端怎么樣突破瓶頸期的一些理解與思考，希望能對部分同學有些啟發(fā)跟幫助，也歡迎留言討論。
什么是瓶頸期
初級前端的定義一般工作經驗是 1 - 3 年，注意是?1 - 3 的工作經驗而不是工作年限。
很多同學經常有這樣的情況，業(yè)務實在太多，能寫完這么多業(yè)務已經花掉日常的時間跟激情，再也沒有時間、精力去折騰了剩下的事情。
每個人的熟練度是有限的，最開始工作的時候，一個小項目或者需求開發(fā)時間需要一個月，而在工作一年或者更短的時間內，接受一定的業(yè)務毒打，使得框架熟練度、業(yè)務理解提升，可以將開發(fā)時間縮短到半個月。然而這個就是普通開發(fā)的極限，沒有辦法再借助熟練度來提高開發(fā)效率之后，就會很進入一段迷茫期。
在現有的技術與熟練度已經完全能滿足現在的業(yè)務需求，公司給研發(fā)安排的內容都是占據預估好的時間。那么這個時候就是初級前端遇到的瓶頸期了?；蛘哒f這是任何一個階段的研發(fā)都會遇到的一個瓶頸期。
減少無效的工作
什么樣的工作是無效（沒有效率）的？

1. 重復的業(yè)務重新寫

2. 重復的功能反復寫

例子1：登錄業(yè)務
大部分活動 h5 都是需要開發(fā)新項目、新的代碼，而很多業(yè)務都需要判斷登錄態(tài)，如果你也碰到這個問題可以嘗試下面的解決方案
將所有的登錄邏輯全部封裝在 sdk 中，在開發(fā)新的活動的時候，可以將 sdk 直接通過 cdn 引入，判斷當前環(huán)境未登錄的情況下，拉起登錄界面，進行登錄。
這里推薦同學用 Rollup 去開發(fā)一個 Library，比較方便。

例子2：權限業(yè)務
在中臺系統(tǒng)中，基本上每個業(yè)務中臺（比如訂單、客服等等）都會有對應的權限控制。每個系統(tǒng)都要寫權限控制的話，會很耽誤時間，即使每次都是從上個項目 copy 過來，也很難保證未來權限系統(tǒng)統(tǒng)一升級的問題。
對微前端的熟悉的同學，可以將整個權限業(yè)務剝離成一個獨立的子工程，然后每個業(yè)務中臺直接引用權限服務即可，這樣可以保持權限業(yè)務的整體升級，并且不會影響到本身業(yè)務同學的開發(fā)。
如果對微前端并不是很熟悉的同學，可以參考 git submodule 或者 npm 包依賴等等，也可以將業(yè)務抽離，統(tǒng)一開發(fā)、升級，只不過更新好的權限服務需要重新構建發(fā)布而已。
例子3：搭建基礎腳手架
每次新開發(fā)項目的時候，會有一些基本的配置都不需要改變，比如：

1. 請求的測試、預發(fā)、生產地址

2. 構建命令，各種環(huán)境的配置

3. 每塊業(yè)務的特殊使用方法（如活動業(yè)務經常會使用到的分享功能等）

可以使用 node 開發(fā)一個自己的 cli 工具，再根據不同的業(yè)務預先配置好多份項目基礎工程，這樣可以根據不同的業(yè)務拉取不同的基礎模板，減少新業(yè)務開發(fā)的搭建、配置時間。
例子4：自己的組件庫搭建
雖然業(yè)內有很成熟的組件庫比如 Ant Design、Vant 等等，但是要貼合每個公司自己的特色與業(yè)務，通用的組件庫肯定是遠遠不夠的。
可以配合 UI 設計，將公司的主體風格、基礎組件全部規(guī)劃一下，有意識的去沉淀自己的組件庫出來。
在后續(xù)的迭代或者新的項目研發(fā)的時候，可以通過自建的組件庫，快速完成界面的基礎搭建。
這件事要主動去推動，不然一般很難落地。

上面的一些小例子，在第一次寫項目的時候就有部分的基礎代碼，在第二個項目開發(fā)的時候就應該有意識的去設計、規(guī)劃將這些內容進行封裝、提取，從而在第三個項目的可以利用之前的設計跟基礎的代碼提高你的開發(fā)速度。
通過 1-3 年的項目訓練，其實你應該具備，從多個項目抽取公共功能、業(yè)務，找到相似、相通點進行合并封裝的能力（拆解項目、組合封裝）。
這個理論上是良性循環(huán)的，可以將縮短后期迭代項目的開始時間，在這個過程中，自己也扮演不同的角色，得到不同的成長與學習的機會。
上述的工作肯定是會額外占用業(yè)余時間，但這也是一個學習、提高的過程。實際上，提高了效率之后，日常工作中反而會有一定自由的時間，去良性循環(huán)這個過程。

借助工具提高效率
vscode 一大把提效的插件，就不多提了，什么代碼格式化、自動提示、資源代理這種，大家都是前端肯定都經常用上。
但是不要把自己局限到前端的這個圈子里面，可以用點額外的工具來提高自己的效率。
這里的效率不僅僅是前端開發(fā)這點內容，把眼界拓寬一點，放在整個研發(fā)工具鏈路上。
在需求-設計-研發(fā)-測試-上線-業(yè)務反饋這整個鏈路中，看看有什么樣的工具可以提高前端的效率
將可預見、將發(fā)生、已發(fā)生與前端有關的問題都考慮進去。
這里面很多事情可以用 node 來做，可以自己研發(fā)，但是要考慮性價比成本的問題，不一定自研或者 node 是最優(yōu)選擇。

Jenkins Or Gitlab CI/CD
每一次的構建是否很痛苦，很耗時，而在多人協(xié)作的時候，還可能因為每個開發(fā)者的系統(tǒng)環(huán)境不同而導致線上異常問題出現。
當你遇到上述問題的時候，首先不要逃避，也不是再打一個新包去解決，而應該引入一個構建工具去幫你完成這些問題。
這些問題在大公司、大團隊可能有運維或者有成熟的 devops 體系去完成，但是這并不影響你去學習、使用來提高自己。
如果團隊中缺乏這些的情況下，使用它將大大節(jié)約你在構建部署這塊的精力。
Fiddler Or Chales

移動端調試一直比較麻煩，除了測試環(huán)境可以使用 vconsole 工具之外，線上可以借助此類抓包工具，快速定位前后端分離項目的一些問題所在。
一般 Mac 系統(tǒng)，Chales 用的比較多，Windows 用 Fiddler 多，選擇你喜歡的就行。
Sentry

從來沒有百分百完美的系統(tǒng)，上線之后的環(huán)境復雜度遠超測試涵蓋的用例，如果想更好地完善你的項目，團隊如果沒有足夠的資源或者成熟的線上預警體系，引入 Sentry 將是一件性價比十足的事情。

這樣可以節(jié)約你在找一些莫名其妙 bug 的時間，也是一件提高效率的利器。
Sentry 是一個日志平臺，分為客戶端和服務端，客戶端(目前客戶端有 Python, PHP, C#, Ruby 等多種語言)就嵌入在你的應用程序中間，程序出現異常就向服務端發(fā)送消息，服務端將消息記錄到數據庫中并提供一個 Web 界面方便查看。Sentry 由 Python 編寫，源碼開放，性能卓越，易于擴展。

Sketch And Pixcook
UI 給設計圖的時候，僅僅肉眼是沒辦法還原的，拿到 psd 又需要會 ps 工具什么的，這里你可以推薦 UI 使用 Sketch 來給你設計圖，既方便體積也小。實在不行，Pixcook 也能通過 psd 自動生成標注的前端代碼，兩者都是設計研發(fā)利器。
不要局限于框架

雷神的靈魂拷問：你到底是雷神還是錘神？放在前端也是一樣，你是一個前端工程師還是 Vue or React or Api 開發(fā)呢？

所有的框架都是開發(fā)業(yè)務的工具，在成熟的體系下，沒有一件工具的價錢是超過人工的。你要考慮的不是怎么做好一個框架開發(fā)，而是怎么成為一個合格的工程師。

現在各種 web 框架層出不窮，各家小程序百花齊放下，多端框架也應運而生。學會一個框架的使用，其實并不難，最多兩個項目，就能夠熟練去使用了，因為框架的誕生就是為了讓你快速去完成項目的。

底層技術與上層設計掌握的足夠牢固，即使換了一個新的框架，你也可以快速上手。但這并不代表，你不需要去了解對應框架的設計與 Api，?而是避免成為 Api 工程師。好好想想自己作為工程師的核心競爭力到底是什么？

當然要是一個框架能玩出花，能解決所有的業(yè)務問題，那也是相當牛逼，但實際情況這種框架或者人很少。

總之能解決業(yè)務的研發(fā)才是能賺錢的研發(fā)，能賺錢的研發(fā)才是好研發(fā)?？赡苓@段話說出來會被打，但現實賺錢的確實都是老板，而不是一個開發(fā)。

另外無論是底層知識、算法、設計的多厲害，但是一定不要脫離業(yè)務基礎。為了面試，很多同學會去刷題、刷算法，確實很有效果，但是最重要的要學會怎么將這些所有的知識體系運用到實際項目中去，讓他能夠發(fā)揮最大的價值。

技術深度相當于內功，肯定修煉的越深厚越好，但是一定要配合業(yè)務運用這層外家功夫，方能成為絕世高手。就好比郭靖一身高強的內力但還是需要降龍十八掌才能御敵。
生死看淡，不服就干
單干
如果你在一個小公司，小團隊的時候，就沒事多折騰折騰自己，有什么新技術就上，前提是：

1. 有一定的心里預期，不成熟的技術坑會非常多，內外部都會有不少的壓力

2. 預留足夠多的時間去試錯，業(yè)務一定是保障第一位

3. 要有一定的備案，如果在新的技術解決不掉問題的時候，能夠快速拿出備案解決

4. 一定不要在主要業(yè)務中使用，如果出現問題，會導致團隊的信任危機，影響后期發(fā)展，不利于后期合作

5. 要有開放的心態(tài)，新的技術運用起來不是優(yōu)越感爆棚，解決問題的同時，可以分享給團隊的每位想要了解同學

團隊
如果你是在一個大公司，一個成熟的團隊，那么能做的事情只會更多。
記住一個點，越大的團隊，業(yè)務鏈路就越多，細節(jié)就越多，能下手的地方就更多，能拿到的資源也會更多。
所以要敢于承擔責任與任務，在關鍵時刻頂住。
比如在新項目啟動的時候要有足夠的勇氣主動去申請承擔。前提條件是，你本身就要扛得住，值得信任，是一個可托付靠譜的人。
或者可以主動參與產品鏈路，與產品、研發(fā)、測試、運維、客服等等一系列與之相關的人員溝通，一起找到目前存在的痛點、難點，然后想辦法去解決。
最好的辦法是將你想做的事情，描述成他們想要的東西，然后他們可以借助你的資源來完成這件事，最后雙贏局面出現，皆大歡喜。

寫在最后

無論在哪都一樣，做技術的切記心浮氣躁，要耐得住寂寞，坐得了冷板凳。

作者：Cookieboty
鏈接：https://juejin.cn/post/6908474217680306189
來源：掘金
著作權歸作者所有。商業(yè)轉載請聯(lián)系作者獲得授權，非商業(yè)轉載請注明出處。

想要了解更多可以點擊：帶你走出瓶頸期。

【尚學堂】web前端HTML教程、web前端CSS教程、web前端零基礎入門教程