拒絕996，有哪些方法能夠提升開發效率的奇技淫巧？

本文已經收錄：GitHub
歡迎訪問，一些大廠面試真題，面試攻略，更多奇技淫巧盡在其中

今天我想與你討論一個每一個開發人員和項目管理者都關心的話題：如何提升開發效率。

我其實也一直很關注這個話題，收集了不少方法讓本身工做變得卓有成效。經過對這些方法的應用，我也能夠算得上是一個高效的程序員：曾一我的在很短期完成了飛信 Web 版客戶端；在 DePaul 上學之餘，幫學校完成了在線教學播放器系統的改造；三個月時間幫公司完成了主站從 jQuery 到 React 的遷移。

若是讓我對學過的這些方法作個整理和總結，再進一步精選提煉，我以爲對我影響最大的是「積極主動」、「以終爲始」和「要事第一」這幾條看似簡單的工做原則。

積極主動，行動起來改變本身

相信你也跟我有過相同的經歷。成爲一個高效程序員，最大的阻力不是來自於不知道方法，而是本身的消極心態。遇到進度延遲、效率低下之類的問題，你就會下意識以爲：

• 時間進度太緊了；
• 我已經盡力了；
• 最近加班太多了沒精神；
• 產品經理太不靠譜了，需求沒想清楚，害的我瞎忙活。

是的，你也知道這些答案都很消極負面，但是怎麼控制本身不這麼想呢？首先你要知道，不管這些事情的本質責任在於環境仍是我的，抱怨排斥的心態對於實際工做的改進是沒有任何幫助的。

固然，不少人也知道抱怨沒用，但具體怎樣才能作到不抱怨，而且積極主動呢？史蒂芬・柯維寫在他的《高效能人士的七個習慣》書中，對這個問題提到了兩個行之有效的建議，咱們能夠結合着軟件開發來分析一下。

想一想再回應

我還記得第一次有人給我介紹單元測試很好用，能讓你效率更高、代碼質量更好時，個人第一反應是不可能，這樣明明要多寫不少代碼，怎麼可能會高效？

因而我有一段時間是很排斥的，直到後來參與一個已經有單元測試的項目，尤爲是在重構代碼的時候，我發現修改了大量代碼後，程序仍是很穩定，當時便以爲應了網友的那句話，「真香」！

每一個人對於外界的刺激都會作出反應，本能的或者習慣性的，就像我前面舉的例子，遇到事情會本能的以爲都是外部緣由。若是一直這樣，那就會進入惡性循環，變得更加消極麻木。

但若是在迴應以前，給本身一點時間想一想，站在積極的方面理性思考一下，就能夠去控制你的本能反應。

因此不少次，就在我脫口而出「不可能」或者「不行」的時候，我提醒本身再想一想。因而我會改口說：「我試試」、「我再想一想」。這樣不少次提醒本身之後，會一點點由「不可能」的本能變成「我想一想」的習慣。

後來有人跟我說 CI（持續集成）很好，我思考過了以後進行了嘗試，在 Github 上建了一個項目，把 CI 搭起來試了一下，以爲真的是很好。若是我仍是秉持着之前的消極心態，不知道又要晚多久才能去嘗試。

減小關注圈，擴大影響圈

我關注不少事情，好比編程語言、明星八卦、國家大事，這些都是「關注圈」。而這其中，要區分哪些事，是我能夠影響和掌控的，這些事則是「影響圈」。

不要總盯着本身沒法改變的部分，你須要要多花時間精力在影響圈上。

好比說，我不能改變 996，至少我能夠利用這時間多學習一點，找機會換一個更好的環境；我不能要求每一個人都寫單元測試，可是我本身的代碼寫了單元測試，這樣項目質量更好了我也更有價值；我不能決定跟什麼樣的人一塊兒共事，可是我願意跟他們分享個人經驗，他們成長了我也受益。

工做一段時間後，你也能夠嘗試去擴大本身的影響圈。

好比說，不少程序員像我同樣，有過很多由於產品經理需求沒想清楚致使返工的經歷，後來我就格外關注產品設計相關的知識，業餘時間本身學習了很多，這就至關於擴大了個人影響圈。

因此後來產品經理給我一個需求，我不須要在開發完成後才抱怨他不靠譜，而是在給我需求的時候就去跟他討論，是否是有可能沒想清楚。

當你不只僅侷限於程序員的角色思惟，擴大了影響圈以後，你就能夠試着向產品經理提出不少有價值的建議，好比：

• 這個佈局在文字很長的狀況下會有什麼變化？
• 若是網絡很慢，加載數據的時候應該顯示什麼？加載失敗顯示什麼？
• 若是數據爲空的時候這個列表應該顯示什麼？

其實「減小關注圈，擴大影響圈」這個道理也很簡單：接受不能改變的，改變能改變的，儘可能擴大可改變項的範圍。

以終爲始，想清楚再開工

若是對比一下我在十幾年前做爲一個新手程序員，和如今做爲一個老手寫代碼有什麼不一樣的話，我認爲在新手階段，我是拿到需求就開始寫，寫到一半發現好像不對，立刻修改，好像還不太對，就這樣反反覆覆，效率很低下。

而如今拿到一個需求，我會先仔細的分析需求文檔，反覆和產品經理確認各類細節，而後作個簡單的設計，考慮清楚模塊怎麼設計，他們之間是什麼關係，而後再寫，寫完還要加上測試代碼。

你知道最大的區別是什麼嗎？我如今作一件事以前，會先想清楚「終」，而後才知道怎麼「始」。因此我先搞清楚需求這個「終」，而後再設計規劃出這個從「始」通向「終」的路線，最後從「始」出發寫代碼，一鼓作氣，不只快，並且質量好。這就是「以終爲始」。

要作到「以終爲始」，就是在作事情的時候注意三點：目標、原則和計劃。

常常停下來想一想目標

我剛畢業參加工做的時候，要開發一個內容管理系統，其中涉及有數據庫訪問，這就須要把數據表的字段和類對應起來，以爲太體力活了，因而我開始寫數據庫生成代碼工具。而要想寫代碼生成工具，我還得學習 Winform 知識……就這樣幾個月過去了，關於這個系統的代碼仍是最開始的幾行！

個人目標是寫一個內容管理系統，結果卻跑去寫代碼生成工具，這樣怎麼能作到高效呢？正確的作法應該是手動完成這幾個類的生成，其實用不了幾分鐘，或者用一個現成的工具。若是以爲代碼生成工具是個有意義的項目，應該另外立項，而不該該影響當前的項目。

這樣的事情在我身上還發生過幾回，因此我後來就逼着本身隔一段時間要停下來想一想：個人原始目標是什麼？我正在作的事是個人目標嗎？若是不是，那麼立刻回到本身的原始目標去。

制定原則

其實大部分很好的編程方法都是須要堅持作纔有效果的，好比說自動化測試代碼，有時候時間進度一緊，就會來不及寫，時間一長，就會欠下技術債務。

因此我給本身定了一個原則：增長一個功能，就要寫自動化測試，若是來不及寫，就給本身寫一條 Ticket。

這條原則我堅持得很好，因此個人自動化測試代碼得以堅持，從而真正幫助我作到高效開發。

你也能夠給本身定一些原則，好比：

• 「先運行再優化 (Make it Work Make It Right Make It Fast)」——也就是在優化代碼以前，先用簡單的方法實現，再考慮怎麼優化，這樣能夠保證設計的簡單，也能夠避免你陷入技術細節中而忽視了原始目標。
• 「不復制粘貼代碼 (Don’t repeat yourself)」——複製粘貼會致使代碼臃腫，不便於維護，提取抽象能夠保持簡潔。
• 「每一個 Pull Request 要儘量小」——這有助於把複雜的任務分解成幾個簡單的任務，簡單的任務更容易高效完成。

有原則了，你才能不忘初心，善始善終。

公開本身的計劃

那麼有了原則就夠了嗎？顯然不是，有了原則，你還要堅決不移地去執行。如何執行呢？作計劃。

剛開始工做時，我是懼怕作計劃的，怕計劃了完不成，問到我工做的時間安排時，我會給一個模凌兩可的答覆，這其實致使了我在實際開發時，缺乏進度壓力，從而迷失在細節中致使延誤進度。

後來我嘗試作出了一些改變，把任務細化，作個簡單計劃，主動給出一個明確的時間點。有了計劃指引和時間點的壓力，會倒逼着本身時刻專一於目標是什麼，「終」在哪裏，還有多少沒有完成，這樣下來工做效率天然而然就會高起來。

經過在作事時，圍繞着目標、原則和計劃這三個點，反覆地刻意地練習，也可讓你慢慢養成「以終爲始」的好習慣。

要事第一，把時間用在刀刃上

做爲程序員，其實大部分時間並不能專一寫程序，總有各類各樣的事情打斷咱們，好比，一會產品經理找你過去開個會確認個需求；一會測試過來找你重現一個 Bug；一會還有同事過來請教你一個問題；微信上老朋友找你敘敘舊；忽然生產環境出故障了，須要立刻去解決。

就這樣一天下去，感受一直在忙忙碌碌，其實並無多少時間在寫程序。這時候怎麼辦呢，對手頭的事情進行優先級管理。

時間四象限也許你不陌生，就是把事情分紅重要緊急、重要不緊急、緊急不重要、不緊急不重要四個象限，不一樣的事情有不一樣的應對策略。

1. 重要緊急的事情立刻處理

好比說，生產環境出故障了，測試環境部署失敗了，這些都是重要而且緊急的事情，只能是立刻處理。

2. 重要不緊急的要事，要花最多的時間在上面

對代碼重構、寫自動化測試代碼、確認清楚需求文檔，這些事情都屬於重要不緊急的事情，可是若是不及時處理，就有可能變成重要緊急的事情，好比不償還技術債務，就可能會變成生產環境故障。

因此這部分事情我會多花時間，重點作。一般我會每段時間只專一作一兩件重要的事，其餘事情儘量忽略，好比前一個階段我主要的工做就是重構前端代碼，這個階段我就在忙排查性能隱患，至於其餘事情，就先放一放。

3. 緊急不重要的事湊一塊兒集中作

像微信的消息通知，可有可無的會議，請教一個不算很急的技術問題，這些都是緊急不重要的問題，然而卻會佔用咱們大量時間。若是時間都用在這些事情上面，必然會佔用在重要事情上所需的時間。

因此我有些小技巧也許你能夠參考。好比我在專一干活時，會全屏幕、關掉全部消息通知，保證沒有消息干擾，忙完一段後再去集中處理。

還有若是有人找我時我正在忙，若是他的事情不是重要緊急的，我會禮貌地告訴他我正好手頭有點事情，大約多少時間後我主動去找他。相應的我也會尊重別人的時間，找別人的時候會先問一下：「你何時有 10 分鐘左右時間，我想請教你一個問題？」

4. 不重要不緊急的事情能不作就不作

不緊急不重要的事也不少，好比說個人 Mac 電腦忽然提示我要更新系統了。我有點強迫症，之前系統一有要升級，我就火燒眉毛要升級到最新，結果一升級系統，半天就不能幹活了。因此後來這種事情，就放在不重要的時間去作，好比周末、睡覺以前讓它慢慢升級。

其實我在作開發的時候，以爲不少很雜的事情也不算太多，真正到後來轉型作管理的時候，才真正體會到什麼叫事情多而雜。但正是源於開發時期就造成的時間四象限方法的運用，讓我能夠在繁忙的時候，保證時間用在有價值的事情上。

要事第一，就是要保證你有限的時間用在最有價值的事情上。

總結

積極主動、 以終爲始和要事第一，這三個原則以及其衍生出來的方法，正是幫助我逐步變成一個高效程序員的關鍵所在，但願也能對你有所幫助。

若是你已經學習了不少相似的原則或者方法，而以爲沒什麼效果，那也許只是由於沒有嘗試把它們變成習慣。你能夠像我同樣，把認同的好的原則或方法，經過反覆的刻意練習，反覆地提醒本身，訓練成習慣，而後用習慣指導你的平常開發。

固然，這樣的改變不會是一天兩天就能完成，但也不用着急，由於習慣的養成須要時間的積累，才能變成條件反射。當你把好的原則或方法變成了直覺反應，天然就會成爲一個高效的程序員。