回答在職前端的疑問：平時工作是主抓業務還是主抓技術？

06-25

來自專欄前端學習指南

這個問題應該是一年到三年前端比較容易遇到的問題：

現在越來越覺的寫業務代碼無趣了，感覺就是一個搬運工。技術棧主要是 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 上的優秀輪子。

類似的輪子我做了很多很多，並且分享給所有同事用。這樣既能提高技術，又有成就感，何樂不為。

你現在用的是 React，其實也是一樣的，你可以在現有的輪子上封裝一些「業務輪子」。

二、拒絕常態化加班

如果你司常年 996，而且不聽勸阻，毫無悔改之意，我覺得你可以

通過上面的業務輪子提高自己的生產效率，這樣你就多出來一些時間
用多出來的時間學習市面上的新技術
投簡歷，找一個不 996 的團隊

我沒有遇到過 996，但是我遇到過大小周的團隊。

如果公司將這種制度常態化，我永遠都是建議離職的，但是我不建議你在做得爛的時候離職，而是在把工作做得很好的時候離職。

一來告訴別人，我離開不是因為我不行。

二來給自己一個滿意的答卷，這樣你會更自信。

總而言之，不要讓自己處於惡性循環中（加班——代碼爛——更要加班——代碼更爛），而是要讓自己處於良性循環中（加班——提升工作效率——加班變少——效率更高）。

有人說我連學習造「業務輪子」的時間沒有怎麼辦，是不是只能強行跳槽？

我說：沒有學習時間你怎麼跳槽？頂多跳到一個差不多的公司。

希望對你有幫助。