說明：
本文已經收錄：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 電腦突然提示我要更新系統了。我有點強迫症，以前系統一有要升級，我就迫不及待要升級到最新，結果一升級系統，半天就不能幹活了。所以後來這種事情，就放在不重要的時間去做，比如週末、睡覺之前讓它慢慢升級。
其實我在做開發的時候，覺得很多很雜的事情也不算太多，真正到後來轉型做管理的時候，才真正體會到什麼叫事情多而雜。但正是源於開發時期就形成的時間四象限方法的運用，讓我可以在繁忙的時候，保證時間用在有價值的事情上。
要事第一，就是要保證你有限的時間用在最有價值的事情上。
總結
積極主動、 以終爲始和要事第一，這三個原則以及其衍生出來的方法，正是幫助我逐步變成一個高效程序員的關鍵所在，希望也能對你有所幫助。
如果你已經學習了很多類似的原則或者方法，而覺得沒什麼效果，那也許只是因爲沒有嘗試把它們變成習慣。你可以像我一樣，把認同的好的原則或方法，通過反覆的刻意練習，反覆地提醒自己，訓練成習慣，然後用習慣指導你的日常開發。
當然，這樣的改變不會是一天兩天就能完成，但也不用着急，因爲習慣的養成需要時間的積累，才能變成條件反射。當你把好的原則或方法變成了直覺反應，自然就會成爲一個高效的程序員。