什麼是瓶頸期
初級前端的定義通常工做經驗是 1 - 3 年，注意是 1 - 3 的工做經驗而不是工做年限。前端
不少同窗常常有這樣的狀況，業務實在太多，能寫完這麼多業務已經花掉平常的時間跟激情，再也沒有時間、精力去折騰了剩下的事情。node
每一個人的熟練度是有限的，最開始工做的時候，一個小項目或者需求開發時間須要一個月，而在工做一年或者更短的時間內，接受必定的業務毒打，使得框架熟練度、業務理解提高，能夠將開發時間縮短到半個月。然而這個就是普通開發的極限，沒有辦法再借助熟練度來提升開發效率以後，就會很進入一段迷茫期。git
在現有的技術與熟練度已經徹底能知足如今的業務需求，公司給研發安排的內容都是佔據預估好的時間。那麼這個時候就是初級前端遇到的瓶頸期了。或者說這是任何一個階段的研發都會遇到的一個瓶頸期。web
減小無效的工做
什麼樣的工做是無效（沒有效率）的？面試
- 重複的業務從新寫
- 重複的功能反覆寫
例子1：登陸業務
大部分活動 h5 都是須要開發新項目、新的代碼，而不少業務都須要判斷登陸態，若是你也碰到這個問題能夠嘗試下面的解決方案算法
將全部的登陸邏輯所有封裝在 sdk 中，在開發新的活動的時候，能夠將 sdk 直接經過 cnd 引入，判斷當前環境未登陸的狀況下，拉起登陸界面，進行登陸。數據庫
這裏推薦同窗用 Rollup 去開發一個 Library，比較方便。npm
例子2：權限業務
在中臺系統中，基本上每一個業務中臺（好比訂單、客服等等）都會有對應的權限控制。每一個系統都要寫權限控制的話，會很耽誤時間，即便每次都是從上個項目 copy 過來，也很難保證將來權限系通通一升級的問題。小程序
對微前端的熟悉的同窗，能夠將整個權限業務剝離成一個獨立的子工程，而後每一個業務中臺直接引用權限服務便可，這樣能夠保持權限業務的總體升級，而且不會影響到自己業務同窗的開發。後端
若是對微前端並非很熟悉的同窗，能夠參考 git submodule 或者 npm 包依賴等等，也能夠將業務抽離，統一開發、升級，只不過更新好的權限服務須要從新構建發佈而已。
例子3：搭建基礎腳手架
每次新開發項目的時候，會有一些基本的配置都不須要改變，好比：
- 請求的測試、預發、生產地址
- 構建命令，各類環境的配置
- 每塊業務的特殊使用方法（如活動業務常常會使用到的分享功能等）
可使用 node 開發一個本身的 cli 工具，再根據不一樣的業務預先配置好多份項目基礎工程，這樣能夠根據不一樣的業務拉取不一樣的基礎模板，減小新業務開發的搭建、配置時間。
例子4：本身的組件庫搭建
雖然業內有很成熟的組件庫好比 Ant Design、Vant 等等，可是要貼合每一個公司本身的特點與業務，通用的組件庫確定是遠遠不夠的。
能夠配合 UI 設計，將公司的主體風格、基礎組件所有規劃一下，有意識的去沉澱本身的組件庫出來。
在後續的迭代或者新的項目研發的時候，能夠經過自建的組件庫，快速完成界面的基礎搭建。
這件事要主動去推進，否則通常很難落地。
上面的一些小例子，在第一次寫項目的時候就有部分的基礎代碼，在第二個項目開發的時候就應該有意識的去設計、規劃將這些內容進行封裝、提取，從而在第三個項目的能夠利用以前的設計跟基礎的代碼提升你的開發速度。
經過 1-3 年的項目訓練，其實你應該具有，從多個項目抽取公共功能、業務，找到類似、相通點進行合併封裝的能力（拆解項目、組合封裝）。
這個理論上是良性循環的，能夠將縮短後期迭代項目的開始時間，在這個過程當中，本身也扮演不一樣的角色，獲得不一樣的成長與學習的機會。
上述的工做確定是會額外佔用業餘時間，但這也是一個學習、提升的過程。實際上，提升了效率以後，平常工做中反而會有必定自由的時間，去良性循環這個過程。
藉助工具提升效率
vscode 一大把提效的插件，就很少提了，什麼代碼格式化、自動提示、資源代理這種，你們都是前端確定都常常用上。
可是不要把本身侷限到前端的這個圈子裏面，能夠用點額外的工具來提升本身的效率。
這裏的效率不只僅是前端開發這點內容，把眼界拓寬一點，放在整個研發工具鏈路上。
在需求-設計-研發-測試-上線-業務反饋這整個鏈路中，看看有什麼樣的工具能夠提升前端的效率
將可預見、將發生、已發生與前端有關的問題都考慮進去。
這裏面不少事情能夠用 node 來作，能夠本身研發，可是要考慮性價比成本的問題，不必定自研或者 node 是最優選擇。
Jenkins Or Gitlab CI/CD
每一次的構建是否很痛苦，很耗時，而在多人協做的時候，還可能由於每一個開發者的系統環境不一樣而致使線上異常問題出現。
當你遇到上述問題的時候，首先不要逃避，也不是再打一個新包去解決，而應該引入一個構建工具去幫你完成這些問題。
這些問題在大公司、大團隊可能有運維或者有成熟的 devops 體系去完成，可是這並不影響你去學習、使用來提升本身。
若是團隊中缺少這些的狀況下，使用它將大大節約你在構建部署這塊的精力。
Fiddler Or Chales
移動端調試一直比較麻煩，除了測試環境可使用 vconsole 工具以外，線上能夠藉助此類抓包工具，快速定位先後端分離項目的一些問題所在。
通常 mac 系統，Chales 用的比較多，windwos 用 Fiddler 多，選擇你喜歡的就行。
Sentry
歷來沒有百分百完美的系統，上線以後的環境複雜度遠超測試涵蓋的用例，若是想更好地完善你的項目，團隊若是沒有足夠的資源或者成熟的線上預警體系，引入 Sentry 將是一件性價比十足的事情。
這樣能夠節約你在找一些莫名其妙 bug 的時間，也是一件提升效率的利器。
Sentry 是一個日誌平臺，分爲客戶端和服務端，客戶端(目前客戶端有 Python, PHP, C#, Ruby 等多種語言)就嵌入在你的應用程序中間，程序出現異常就向服務端發送消息，服務端將消息記錄到數據庫中並提供一個 Web 界面方便查看。Sentry 由 Python 編寫，源碼開放，性能卓越，易於擴展。
Sketch And Pixcook
UI 給設計圖的時候，僅僅肉眼是沒辦法還原的，拿到 psd 又須要會 ps 工具什麼的，這裏你能夠推薦 UI 使用 Sketch 來給你設計圖，既方便體積也小。實在不行，Pixcook 也能經過 psd 自動生成標註的前端代碼，二者都是設計研發利器。
不要侷限於框架
雷神的靈魂拷問：你究竟是雷神仍是錘神？放在前端也是同樣，你是一個前端工程師仍是 Vue or React or Api 開發呢？
全部的框架都是開發業務的工具，在成熟的體系下，沒有一件工具的價錢是超過人工的。你要考慮的不是怎麼作好一個框架開發，而是怎麼成爲一個合格的工程師。
如今各類 web 框架層出不窮，各家小程序百花齊放下，多端框架也應運而生。學會一個框架的使用，其實並不難，最多兩個項目，就可以熟練去使用了，由於框架的誕生就是爲了讓你快速去完成項目的。
底層技術與上層設計掌握的足夠牢固，即便換了一個新的框架，你也能夠快速上手。但這並不表明，你不須要去了解對應框架的設計與 Api， 而是避免成爲 Api 工程師。好好想一想本身做爲工程師的核心競爭力究竟是什麼？
固然要是一個框架能玩出花，能解決全部的業務問題，那也是至關牛逼，但實際狀況這種框架或者人不多。
總之能解決業務的研發纔是能賺錢的研發，能賺錢的研發纔是好研發。可能這段話說出來會被打，但現實賺錢的確實都是老闆，而不是一個開發。
另外不管是底層知識、算法、設計的多厲害，可是必定不要脫離業務基礎。爲了面試，不少同窗會去刷題、刷算法，確實頗有效果，可是最重要的要學會怎麼將這些全部的知識體系運用到實際項目中去，讓他可以發揮最大的價值。
技術深度至關於內功，確定修煉的越深厚越好，可是必定要配合業務運用這層外家功夫，方能成爲絕世高手。就比如郭靖一身高強的內力但仍是須要降龍十八掌才能禦敵。
生死看淡，不服就幹
單幹
若是你在一個小公司，小團隊的時候，就沒事多折騰折騰本身，有什麼新技術就上，前提是：
- 有必定的內心預期，不成熟的技術坑會很是多，內外部都會有很多的壓力
- 預留足夠多的時間去試錯，業務必定是保障第一位
- 要有必定的備案，若是在新的技術解決不掉問題的時候，可以快速拿出備案解決
- 必定不要在主要業務中使用，若是出現問題，會致使團隊的信任危機，影響後期發展，不利於後期合做
- 要有開放的心態，新的技術運用起來不是優越感爆棚，解決問題的同時，能夠分享給團隊的每位想要了解同窗
團隊
若是你是在一個大公司，一個成熟的團隊，那麼能作的事情只會更多。
記住一個點，越大的團隊，業務鏈路就越多，細節就越多，能下手的地方就更多，能拿到的資源也會更多。
因此要勇於承擔責任與任務，在關鍵時刻頂住。
好比在新項目啓動的時候要有足夠的勇氣主動去申請承擔。前提條件是，你自己就要扛得住，值得信任，是一個可託付靠譜的人。
或者能夠主動參與產品鏈路，與產品、研發、測試、運維、客服等等一系列與之相關的人員溝通，一塊兒找到目前存在的痛點、難點，而後想辦法去解決。
最好的辦法是將你想作的事情，描述成他們想要的東西，而後他們能夠藉助你的資源來完成這件事，最後共贏局面出現，皆大歡喜。
寫在最後
不管在哪都同樣，作技術的切記心浮氣躁，要賴得住寂寞，作得了冷板凳。