這個問題應該是一年到三年前端比較容易遇到的問題：
現在越來越覺的寫業務程式碼無趣了，感覺就是一個搬運工。技術棧主要是 vue + elementUI / react 。 前端工作已經有一年半多的時間了。我今年三月份突然想學習一下前端基礎，在知乎上面知道的你，也報了你的班。雖然明面上用框架寫業務程式碼寫的賊6，也得到了別人的認可，但是實際上我知道我只停留在會寫業務程式碼，並不知道技術原理的層面上。 最近幾個月挺牴觸公司業務的，我只想學一些前端基礎。不好的是現在這家公司996，給我的空餘時間比較少。最近公司的事情只是應付成完成，在業餘時間看你的視訊，寫一點部落格，我覺得這樣挺好的。未來幾年應該都會呆在上海，以後的目標是技術管理。 現在發現業務與學習碰撞了，我現在牴觸業務，想去多學習前端基礎的東西。平時工作是主抓業務還是主抓技術，我該怎麼選擇？
確實，你已經從新手變成了一個「熟手」，也可以勝任公司的工作安排。
只不過總覺得在日復一日地重複昨天的自己。
我也有過這種階段。我說一下我的應對措施。
一、不存在純粹的業務程式碼
將程式碼分為「業務程式碼」和「技術程式碼」是一種簡單的二分法。但是實際情況可能並不是這樣。我的經驗中還有第三種程式碼，就是「業務技術程式碼」。
通俗地講，這種程式碼就是專門給公司的業務造的輪子。
舉例說明，假設你司常年使用 jQuery，你要做的就是用 jQuery 做做表格篩選、分頁、輪播、表單驗證等。這種工作看起來很沒勁吧？
對於這種工作，我期望一個前端的成長路線應該是這樣的：
- 第一階級是應付工作。你通過搜尋、查 Stackoverflow、複製貼上等方式，將需求完成。程式碼看起來有點「麵條」，但是能正常工作。
- 第二階段是抽象分類。這個階段你發現公司給你的需求是有規律的，表格篩選就那麼幾種模式，表單驗證就那麼幾種規則，於是你寫文章總結，或者是把程式碼固定出一個模板，這樣一來，公司再來同樣的需求，你可以非常快地搞定。
- 第三階段是造輪子。第二階段的程式碼在經過業務需求的驗證後，你已經對這些程式碼的質量很有自信了，那麼你就可以將這些程式碼抽離成一個個「業務輪子」，然後把這些輪子分享給前端同事和後端同事，讓他們的需求也能又好又快地完成。
- 第四階段是優化。你需要為這些輪子提供完善的使用文件、測試用例，如果你的公司人很多，你還要準備一個「推廣計劃」
這是一個非常好的成長路線，因為這就是我在阿里給自己規劃的路線，而且我就是這麼踐行的。
你可能對第三階段的「業務輪子」沒有概念，那我舉個例子。
在我加入團隊之前，他們做分頁要經過很多步驟，包括
- 複製 HTML 結構
- JS 初始化
- 後端介面商定
- CSS 調整
我做成輪子之後，就變成下面這樣：
<div data-role="pager" data-total-page="10" data-page="3"
data-auto-page data-theme="taobao"></div>
複製程式碼使用者只需要提供總頁數、當前頁數和主題名稱即可，後端介面的引數已經統一成在 URL 加 page=? 不需要再商定，使用者點選分頁器中的數字會有兩個結果：
- 如果有 data-auto-page 欄位，就自動變更當前頁面的 ?page=xxx 引數
- 如果沒有 data-auto-page 欄位，就觸發 'pagechange' 事件 這就是一個「業務輪子」，為公司的業務量身定做一個輪子。
在做的過程中你需要總結需求，分析使用者（開發者）的使用習慣，還要參考 GitHub 上的優秀輪子。
類似的輪子我做了很多很多，並且分享給所有同事用。這樣既能提高技術，又有成就感，何樂不為。
二、拒絕常態化加班
如果你司常年 996，而且不聽勸阻，毫無悔改之意，我覺得你可以
- 通過上面的業務輪子提高自己的生產效率，這樣你就多出來一些時間
- 用多出來的時間學習市面上的新技術
- 投簡歷，找一個不 996 的團隊
我沒有遇到過 996，但是我遇到過大小周的團隊。
如果公司將這種制度常態化，我永遠都是建議離職的，但是我不建議你在做得爛的時候離職，而是在把工作做得很好的時候離職。
一來告訴別人，我離開不是因為我不行。
二來給自己一個滿意的答卷，這樣你會更自信。
總結
總而言之，不要讓自己處於惡性迴圈中（加班——程式碼爛——更要加班——程式碼更爛），而是要讓自己處於良性迴圈中（加班——提升工作效率——加班變少——效率更高）。
有人說我連學習造「業務輪子」的時間沒有怎麼辦，是不是隻能強行跳槽？
我說：沒有學習時間你怎麼跳槽？頂多跳到一個差不多的公司。
希望對你有幫助。