如何提升編程效率

閱讀英文資料
 對於全棧工程師來講，遇到問題時經常會求助搜索引擎，尤爲是在學習新的編程語言，或者學習某個框架的新版本的時候。這是最快速的方案，在不少時候比看官方文檔還有效。有的時候咱們只是想快速瞭解一個新的技術，或者快速上手，這時候也會用到搜索引擎。
爲何我推薦使用英文，而不是使用中文搜索，有這樣幾個緣由：

英文的技術資料更多
 在全世界範圍內，IT工程師廣泛使用英文（即便中國工程師的數量也許更多），因而用英語寫做就有了最大的讀者羣，而後有更多的人用英語寫做……。
在Google中用英文搜索技術問題，每每能獲得很詳細的說明，以及相應的代碼示例。有的時候您會進入英文維基百科，裏面有關於詞條的詳細解釋，包括歷史、版本、理念、競爭者，等等。有的時候您會進入一個教程（tutorial），裏面會詳細介紹完成一個任務的整個流程，甚至還可能貼心地提供工程示例文件的下載，這是新手學習的最好方法。

StackOverflow有完善的鼓勵機制
 內容篩選機制、嚴格的內容把關政策，這讓Google的內容質量很高。若是您鍵入的關鍵詞足夠多，那麼您頗有可能看到不少StackOverflow的問答連接。
 StackOverflow是一個與計算機編程相關的問答網站，也是最大的IT工程師平臺。在這裏有不少知名開發者，因爲有完善的系統鼓勵政策，他們都很熱衷於回答其餘開發者遇到的問題。用戶能夠在網站免費提交問題，瀏覽答案，贊同或者反對答案。StackOverflow是一個英文網站，全部用戶都必須用英文提問和回答問題。不少時候，在一個問題下都會有多個回答，有經驗的用戶能夠贊同或者反對其餘人的回答，新手能夠根據每一個回答的贊同數來判斷回答的可靠性。
 關於StackOverflow，還有一點題外話。StackOverflow由兩個世界著名的博客做者共同建立，Jeff Atwood和Joel Spolsky。Jeff Atwood提出了著名的Atwood定律：「任何可以用JavaScript實現的應用系統，最終都必將用JavaScript實現。」JoelSpolsky多是軟件工程師中寫博客最有名的一位，他是「Joel on Software」博客的做者，讀者人數能夠排進全世界前100名。兩位創始人對工程師心理有着深入的洞察，包括追求榮譽感這一特色，因此他們設計的StackOverflow的鼓勵機制，取得了巨大的成功。

Google的搜索能力很是強
 Google在搜索引擎方面的技術實力能夠說是絕對領先，它比排名第二的搜索引擎的技術實力和用戶體驗要強一大截。我曾經對比了大量詞彙在不一樣搜索引擎中的搜索結果，有時候差很少，有時候差異很大，Google老是好得多。因此即便您要搜索中文問題和詞彙，也仍然建議使用Google。

英語世界的語言風格比較嚴謹
 中文互聯網世界上的語法通常比較口語化，並且不太在乎語法正確性和邏輯的嚴謹性。在整篇文章的行文和邏輯構建上，英文也每每更嚴謹。
若是您的英文不夠好，沒有關係。在長篇的英文技術文章或者StackOverflow中，寫做者都會有意使用最簡單的詞彙和語法。若是您能編程，您就能理解這些簡單的英文

時間管理四象限
 一個領導說過，若是您平時沒有作重要的事情，就會發現本身經常在作緊急的事情。若是您平時沒有注意鍛鍊身體，就會經常去醫院，花費更多時間。若是沒有培養後輩，爲每一個項目設置接班人，就會經常須要處處救火。若是您沒有配置好版本管理系統就開始工做，就會浪費更多時間去找回丟失的代碼。若是偷懶硬編碼（hard code）了一些變量在代碼中，後續必定會花費更多時間去調試。時間管理四象限將咱們平時須要作的事情分爲4類：重要並且緊急、重要但不緊急、不重要但緊急、不重要並且不緊急。

 時間四象限教咱們把不一樣的事情分在不一樣象限之中，而後採用不一樣的處理方法。
第一象限是重要又緊迫的事情。好比線上出現嚴重bug、服務器出現安全漏洞、用戶的投訴，等等。對於這些問題，是考驗本身的經驗和判斷力的時候，用本身最好的判斷力，當即執行。不過也要意識到，在這一象限的問題每每是第二象限的問題沒有制定好的計劃而滑落過來的，若是大部分的工做都落在第一象限，說明仍是在「瞎忙」。

 第二象限是緊急但不重要的事情。好比會議、一些可轉交的需求，等等。這種事情每每會因爲對方強烈的呼聲讓您認爲它處於第一象限，有一種「這事很重要」的錯覺。咱們花不少時間在這裏打轉，其實只是在知足他人的需求，而沒有關注本身的職責。對於這種事情應該請他人代勞，不必定是本身的下屬，還能夠是平級的同事。有一些會議不必定須要本身去參加的，能夠提早跟主持人（項目經理）溝通。

 第三象限是重要但不緊急的事情。好比一些線上體驗優化計劃、團隊的長期發展方向和我的培訓等。有一次老闆提出了線上的一個體驗問題，咱們覺得這是第一象限的問題，立刻執行。結果老闆說，這個事情不須要您們這麼快去執行，但願能夠作深刻一點的調研。建議工程師把80%的工做投入到該象限中，避免「瞎忙」。

 第四象限是不重要也不緊急的事情。逛論壇、刷朋友圈就屬於這一象限。簡而言之就是浪費生命，因此根本不值得花半點時間在這個象限。但咱們每每在1、二象限來回奔走，忙得焦頭爛額，不得不到第四象限去療養一番再出發。因此咱們要避免浪費時間在第四象限，也不要疲於奔命，各處「救火」。
有時候咱們覺得是外部緣由讓咱們分神，其實更重要的緣由是人的精力被耗盡了。咱們在一些覺得是消遣和休息的活動上投入了不少時間（好比刷朋友圈、玩遊戲），回到工做的時候，並無感到重返工做的舒暢，反而精力渙散，容易分神。咱們身體上的勞累讓咱們的精力沒法集中。

消除重複工做
 重複的工做應該交給計算機去幹，這是咱們都知道的一個道理。
有趣的是，咱們每每不知道咱們的時間花在哪裏，有一個辦法就是詳細地記錄本身一天的時間消耗。在合併代碼上面花費太多時間？仍是提交測試？發佈流程繁瑣？編譯過久？切圖的工做枯燥無味？
 第一步即是識別出本身的時間花費在了哪裏，以此做爲優化的目標。
 有了優化目標以後，第二個思考的問題是，可否使用已有的工具——免費的或付費的——來無縫銜接在已有的流程中。若是新的流程成本過高，那就沒法有效推動。普通工具能夠用英文在GitHub上搜索相關的關鍵詞，前端開發者能夠在Gulp和Grunt社區尋求幫助。
若是不能使用已有的工具的話，就要本身去編寫了。在語言的選擇上能夠從幾個角度考慮：工具的使用者是誰？若是須要分發給同事安裝，那麼他們使用什麼系統？Windows仍是OSX？若是使用Web來做爲用戶接口，那麼就可使用任何您喜歡的語言。用腳本語言開發小型工具很是快，無需編譯便可運行。Paul Graham在《黑客與畫家》裏面就提到過他使用Lisp語言來快速開發的經歷。
 給本身留出不被打擾的時間
  當咱們被QQ、微信、RTX、電話等提示工具打擾時就會頻繁分神，這使得專一力現在已成爲稀缺資源。
 Paul Graham在一篇文章中說過，創做者的時間計劃與經理的時間計劃是很是不同的。工程師做爲創做者，遵循創做者的時間計劃。編寫程序須要大量的精神投入，須要整塊連續的時間思考，因此工程師工做時是不但願被打擾的，若思路被打斷則後果很嚴重。
Facebook的每週三是沒有會議的日子（No Meeting Wednesdays），每個團隊成員都知道，除非萬不得已，不要在這一天安排任何會議。事實證實這對團隊的效率頗有好處，它鼓勵全部人（包括產品經理）成爲「作事情的人」而不是「計劃事情的人」，並且全部人都有一整塊的時間工做。對於遠程工程師來講，還能夠選擇在家裏工做，根本不用出如今辦公室。

番茄工做法
 有些時候，咱們沒有辦法獲得一成天的大塊、連續的工做時間，爲此能夠採用短迭代的工做方法，高效地利用每一小塊的工做時間。
 我在跟Facebook的工程師聊天的時候，發現他們都很注重鍛鍊身體，天天早上開始工做以前都會花一個小時跑步和健身，而後洗澡吃早餐，再開始一小段高效的工做時間。下午的工做時間中也會穿插一些運動和甜點時間，等等，不會像國內的工程師們，須要長時間地坐在電腦前。這種狀態的轉換讓他們的效率獲得了很大的提高。因此包括騰訊在內的一些國內公司如今也開始把健身房和團隊運動做爲一項員工福利，有時候還會組織晨跑或者徒步等團體運動。
番茄工做法」是由弗朗西斯科-西里洛於1992年創立的一種微觀時間管理方法。使用番茄工做法，選擇一個待完成的任務，將番茄時間設爲25分鐘，專一工做，中途不容許作任何與該任務無關的事，直到番茄時鐘響起，而後在紙上畫一個X，短暫休息一下（5分鐘就行），每4個番茄時段則多休息一下子。
 番茄工做法極大地提升了工做效率，還會有意想不到的成就感。爲何25分鐘是一個比較好的時間點？由於若是太短，思惟尚未恢復過來，就立刻要被打斷，不利於創做。番茄工做法主張在25分鐘時間段內專一地完成高質量的工做，接着是5分鐘的休息。若是讓壓力系統一直工做，而不借助心智休閒進行調節，一些症狀會找上門來。

跨界思考
 有時候項目會頻繁變更，從A計劃臨時轉變成B計劃，而後再回到A計劃的事情家常便飯，這是浪費工程師精力的最大因素。
 從項目的角度來說，也許這是好事情，誰也不但願把很差的產品發佈出去。每一個人都但願本身作的產品可以成功，可是不是作重複的腦力勞動。歸根結底，是雙方在溝通的過程當中充滿了障礙，不一樣崗位的人的思考問題的方式不一樣。
 設計師們是典型的浪漫主義者，他們的世界裏沒有公式、沒有定理、永遠沒有標準答案，更多的是用發散的思惟去構思創意，更容易產生好想法。而工程師注重邏輯的嚴謹性、技術的可行性，他們每每用「我是否可以作到」和「我要花多少時間才能作到」這個思惟在思考。
 那麼這種矛盾如何解決？在初級設計師和初級開發者之間，咱們鼓勵他們頻繁溝通，把本身的想法用對方能懂的語言說出來。在高級設計師和高級開發者之間，界限就沒有那麼明顯了，我鼓勵他們幫對方作一些工做。這說明什麼呢，溝通當然重要，跨界學習更加劇要！當雙方帶着徹底不一樣的思路去討論一個話題，討論出來的結果必然是雙方妥協的產物，而不會是最優的結果。
不少工程師都向往國外大公司的「工程師文化」。爲何？由於「工程師文化」表明了工程師是產品開發中的強勢方，在跟產品和設計師的溝通中有更多的話語權（甚至某些產品跳過設計師和產品經理）。可是我認爲，這是由於國外的工程師有更高的跨界思考能力，才獲得了本身的投票權。不少工程師主導的項目，界面不華麗，可是可用性都很是高。這就是跨界能力帶來的另外一個好處，能夠作一個「產品創做者」。
 過去跨界學習的成本很高，大部分人都不敢輕易嘗試。但現在互聯網時代給咱們帶來了機遇，天天上網均可以看到其餘領域名人寫的文章和微博，經過查看這些內容，咱們就能對本來徹底陌生的領域有一個感性的認識。時間一久，咱們就可以在潛移默化中理解另外一個領域的從業者的思惟方式，當您開始跨界學習以後，就會增長更多的機會.
 我在工做的這幾年中也在漸漸受到設計師和管理者的影響，開始學習設計師和管理者的思惟方式，因此有時候我被認爲是「有一點設計感受的工程師」，但我仍在學習。或許每一個工程師會在不一樣的環境中跨不一樣的界，可是在將來，我認爲跨界出來的那部分能力才真正定義了「您」。
紙上頭腦風暴
 我使用過不少工具，好比MindMap類軟件，或者簡單的記事本軟件、手機上的繪圖軟件等。最終，個人經驗是，在電腦上工做以前，先在紙上畫出本身的想法。筆跟紙是最靈活、最容易修改、成本最低的頭腦風暴方式。
 好比在寫一篇文章前，就能夠先畫一個思惟導圖，把頭腦風暴出來的全部關鍵詞都列出來，而後再根據金字塔式的寫做方式層層分解。若是是開發一個軟件，或者寫一個腳本程序，能夠把每一步的主要工做都寫下來，相似僞代碼，可是抽象層級更高一點。

使用版本控制和構建系統
 數據代表，對於沒有使用版本控制工具的工程師而言，浪費在代碼合併、版本回溯以及bug修改上的時間遠遠超過了使用版本控制工具的工程師。因此，這是針對全部人都適用的建議，儘快使用版本控制工具。
 好的構建系統可讓工程師徹底從枯燥的操做中解脫出來。在極端狀況下，不使用構建系統的工程師可能要花費80%的時間在編譯和等待生效、清除緩存等操做上。

加班是一種文化？
 我不認同加班是一種「文化」。加班就是加班，是因爲工做沒有完成致使的。
 在一個項目和人力都很穩定的團隊中，有兩種緣由會致使加班。
 一種是糟糕的項目管理，領導失職，沒有安排好工做。
 第二種是員工能力不夠，效率不高，沒有按時完成目標。在這兩種狀況下，我都建議您跟領導去溝通。
 我時常聽人抱怨說，團隊有加班的氛圍，他早早完成了工做，但是看見你們下班後還待在座位上（尤爲是領導還在），就很差意思本身一我的下班，只好留下來「陪加班」。甚至，由於長期在這種環境下工做，有人認爲領導在升職加薪的時候優先考慮愛加班的人，因此白天就慢慢吞吞，晚上就開始加班。
 我認爲這種狀況也許只是個別人的認知問題：認爲領導推崇加班的氛圍，以及領導按工做時長來判斷投入度，以此做爲升職加薪的考量因素；或者認爲領導不知道誰工做成果更好，因此按勞累程度來判斷……全部這些認知都是由於茫然和不自信，不知道本身的核心競爭力是什麼，也不知道老闆真正須要的是什麼。拿工做時長來拼，這仍是體力勞動時代打工者的心態在做祟。
稍有常識的老闆，或者接受過一點點管理培訓的領導者，都知道評估員工是看結果，而不是看努力和過程。您在把老闆當傻子，拼命展現「辛苦」，結果更加不如意，只好每天抱怨：「小A這個傢伙天天不加班，怎麼老闆那麼喜歡他，升得比我還快！」
 工程師須要提升本身的溝通能力，若是你們由於緊急項目等緣由在加班，您不妨過去問問，能不能幫到什麼忙。用積極的態度去思考問題，而不是消極地坐在那裏，浪費本身的時間和情緒。大部分老闆都會很歡迎員工主動的溝通。
 若是團隊內年輕人比較多，有些時候他們下班後喜歡留在辦公室，並非由於項目須要，而是公司內有免費的晚餐、空調、飲料、電腦……幾乎是一個單身宅男須要的一切了，因此他們喜歡待在公司也是比較容易理解。我經常跟他們說的是，下班以後儘可能不要處理工做需求了，多點時間自我學習，或者準備一些分享，甚至作一些編外項目（side project）。重點是，不要加班作白天遺留下來的工做。
 若是下屬常常須要加班才能完成工做，我會認爲是管理者的失職，一方面我會看看是否給員工安排的工做太多，可否轉移一些給其餘人，另外一方面也會看是否須要借調其餘資源，或者招聘更多人手。
 加班狂的英文是Workaholism，直譯爲「工做上癮」。長期加班的人會有一種錯誤的觀念，就是午夜鏖戰全情投入項目的標誌。他們不會去找高效的方法，由於他們確實喜歡加班。這每每致使惡性循環，熬夜和過量的工做讓人疲憊，影響人的思惟和判斷力，這樣更加沒法找到高效的方法來完成工做。
 最後，過量的工做和壓力嚴重影響健康，最終致使一些慢性病，甚至猝死。咱們常常在媒體上看到某IT公司員工猝死，臨死前還在朋友圈發加班的照片。
 我不肯定家庭情況、我的健康或者具體項目對猝死員工產生了什麼影響，但我認爲一個接受太高學歷教育的成年人，應該有能力權衡本身的健康、家庭的責任，以及長期工做回報。每一個人均可以有本身的選擇。工做上癮者不光把本身逼上絕路，也把老闆逼上絕路。您認爲本身能高負荷工做堅持一個月，他就認爲您還能堅持半年。

 總結一下，加班不是一種「文化」，它每每是咱們心中假想的老闆，還有媒體渲染出來的一種畸形工做模式。在這種模式中，加班狂習慣了熬夜和過量的工做，他們每每也給了老闆長期加班的預期，同時也帶來低迷的士氣，以及疲倦的身體。

延伸閱讀: 1.《軟件隨想錄：程序員部落酋長Joel談軟件》（美）Joel Spolsky，人民郵電出版社 2.《卓有成效的程序員》（美）Neal Ford，機械工業出版社