winty：工做很忙，如何破局

背景

這個問題，不少人問過我。我都沒有具體回答過，問得多了，我以爲我有必要一次性，將想說的都寫出來。這樣之後誰要是問我，我就給他甩這篇文章，完美。

迷茫

工做很迷茫，我以爲大部分的緣由以下：

1. 業務需求多，加班也作不完的程度
2. 業務簡單，感受技術含量低
3. 背景通常，不知道如何提高本身
4. 其餘

無論什麼緣由都好，反正迷茫了。其實這些問題，我感受人人都會遇到，只能多是在不一樣的技術階段遇到罷了，包括我本身，也確確實實都遇到了。雖然我不以爲本身破局成功了，可是我能夠分享一下我目前的應對方法，你能夠參考一下看看對你是否有幫助。

破局

業務需求多，加班也作不完的程度

1. 以個人認知，業務需求就不會有作完的時候。這個問題，我以爲若是你剛入職新公司，對業務不熟悉，那麼你只能好好加班，慢慢總結，儘量地加快熟悉項目的速度。這裏的總結，能夠總結這些內容：

• 記錄開發流程。一般都有好多步驟，不一樣的系統，甚至須要各類權限和帳號。都好好走一遍流程，以圖文的形式記錄下這個開發流程的過程，造成本身的筆記，爭取作到，只問一遍同事，就學會了，熟悉理解了。若是大家沒有什麼文檔或者文檔過舊，恰好你能夠沉澱一個新人文檔了，多棒！

• 記錄通用業務代碼片斷。一個團隊的業務方向一般是固定的。也就是說確定是不少東西能夠複用，或者說你寫了以後能夠被複用的。這種狀況下，若是是大的功能模塊或者邏輯，能夠造成一個 npm 包，抽離出來以供複用。小的片斷能夠放 util 中，甚至，直接 copy 到本身的筆記本中，方便本身查找使用便可。雖然搬運代碼確實沒什麼含量，可是在你理解的前提下搬運倒是省時快捷的最佳方法，學會站在歷史的肩膀上。

• 梳理痛點，逐個攻破。開發中遇到痛點，或者靈機一動的點，必定必定要及時記錄下來，好比我，始終會有一個叫價值過億的想法的筆記目錄。你能夠只寫一句話，記錄一下這個痛點，痛點就是你以爲很耗時，或者很不合理，浪費你時間的地方。先記錄下來，而後找個時間逐一梳理應對。站在問題的角度上，若是我以爲這東西很難用，那麼我指望是什麼，怎麼樣才能讓我本身以爲好用呢。對於想法就是，我想作一個什麼東西，解決什麼問題的東西。這些靈光一現若是沒有及時記錄，一般過了也就忘了。

• 提升本身的抽象能力，封裝能力。固然，這個說得有點抽象，須要靠本身感悟了。如何感悟，那就是多閱讀優秀的大神的代碼，看看別人在寫代碼的時候，都怎麼寫的，怎麼設計的，這種跟本身的對比，優劣如何。這東西，看多了，總能學到點皮毛的。

1. 向上反饋，拋出風險點。這怎麼說呢，加班雖然不可避免，可是也不用走 007 的節奏，本身根據本身的實際狀況，定一個本身能夠接受的加班範圍。我本身的話，目前能接受的最大加班時間是 10115，若是項目趕着上線週末也能夠加班，可是不能長期連續週末加班。若是你盡力了，仍是沒法按時交付，那麼就直接跟上級反映。有人說，老闆才無論你，作不完就要走人了，那麼若是是我遇到這種老闆，我會本身走人。

2. 強行安排自由時間。本身在評估需求的時候，能夠天天留個半小時到 1 小時做爲自由時間，那麼你就利用這點小時間去作本身特別想作的事情，這裏個人一個建議是優先作工做相關的一些基建/輪子的調研或者代碼編寫。畢竟提升生產力纔是工做中最須要的，並且基於業務的技術更有意義也更有挑戰。

業務簡單，感受技術含量低

1. 若是你業務簡單，沒啥技術含量，你還瘋狂加班，我以爲這是矛盾的。首先，若是沒啥技術含量的簡單需求，一般都是有對應的工具或者系統去改進，進而提升生產力。或者你欠缺的是這樣的系統，那麼你能夠調研一下，相關背景下，一些開源項目/大公司的分享實踐。好比我總是在切圖，作頁面，那麼你是否想過可視化搭建？是否想過有根據設計稿輸出頁面代碼的項目？是否想過物料沉澱，重複提取利用？都是有什麼能夠挖掘的點的，或者是本身的認知和水平，尚不知道罷了。

2. 多參與一下大公司的技術分享大會，這種一般都是基於具體的業務作了一些提高工做的，能夠增加本身的見識和思考廣度。

3. 若是你的公司或者團隊，實在是什麼都沒有，那麼你只能靠本身，打造本身的社區影響力，好比寫博客，參與開源項目。你能夠像我同樣，寫文章，發掘金，搞公衆號等。這些都是能夠嘗試的方向。

4. 加羣交流，關注前端 Q，學習文章，關注前端動向，閱讀各類源碼，思考這些框架或輪子的設計亮點，反正就是多思考，融會貫通，感悟出本身的東西。

5. 跳槽。若是你以爲在一個公司，原地踏步很久了，換個環境從新開始其實不失爲一個選擇。

背景通常，不知道如何提高本身

首先，背景通常，絕對是相對的。閃閃發光的人是大，但不是滿大街都是，咱們大多數都只是個普通人。既然你們都是普通人，又何須在乎什麼背景不背景的呢。默默學習就是了。我總結幾個我本身的方法分享給你們：

1. 總結工做中/公司中本身能接觸到的項目，去了解這個項目，能夠從背景，0 到 1 作什麼，1 到 2 作了什麼去了解。最重要的是數據，這些變化直接的數據是如何體現的。總結出來。

2. 設立假想敵，好比同是前端方向的，本身要達到他的多少，或者說高於他多少(最直接的體現是 )，時刻鞭策本身努力。

3. 替換框架中的思想/輪子/方法，最簡單的，假設你的項目用了 jq，你可否用原生 js 實現，進而替換項目中的方法呢。不要總是說項目簡單，沒亮點沒挑戰。再簡單的項目，均可以本身挖掘難點的，就看你有沒有勇氣和耐心去作罷了。再好比小程序不支持 store，你可否實現一個呢？其實都是本身爲本身找的藉口罷了，或者說你以爲這種拿不出去裝逼，不想動手。可是，若是沒有前期的積累，又有幾我的能夠一步登天呢？前端人，踏實點吧。

4. 多接觸一些前端進階必須的東西。原理源碼/自動化（性能/測試/部署發佈）/效能方案(持續集成/微前端/node 中間層)等等

最後

不積跬步無以致千里。當你以爲本身原地踏步的時候，不妨好好反思一下；當你想去實踐一些大項目的時候，不妨拿小項目練練手，慢慢沉澱；當你加班不少的時候，從項目找切入點去學習提高。

沒有那麼多的手把手教，前端都是靠本身悟的，奮鬥吧，騷年！

更多

這個問題算是粉絲的問答了，平時不少人會私聊我問題，可是一方面我太忙了通常不私聊回答，另外一方面，想回答好一個問題真不是三言兩語能夠說清楚的。所以，前端Q開了一個前端感悟專輯，我決定專門寫你們問個人問題且我以爲有意義的問題，感興趣的朋友能夠留意一下哦。

若是你有什麼問題想問個人，歡迎在留言區留言哈，我會看着答的，嘿嘿～

最後

• 歡迎加我微信(winty230)，拉你進技術羣，長期交流學習...
  

• 歡迎關注「前端Q」,認真學前端，作個專業的技術人...