大師級的程式設計師，都在用這些工作法

程式設計師是一個忙碌的職業，與這個職業聯絡在一起的詞兒，通常是忙碌、加班、熬夜、過勞、亞健康……當忙碌成為了主旋律，“高效”一詞就自然浮出了水面。

可是，程式設計師工作效率是由程式設計能力決定的嗎？答案是“未必”。

這些年，我一直在研究一件事兒：為什麼那些大師級程式設計師，可以兼顧 N 倍於一般人的工作，還有條不紊？他們究竟用了什麼工作法？根據我的觀察與總結，他們往往繞不開下面四個工作原則。

• 以終為始

• 任務分解

• 溝通反饋

• 自動化一切

下面，就給大家先介紹前兩個工作原則。

以終為始DoD

DoD（Definition of Done，完成的定義），從名字便不難看出，它就是為了解決軟體開發中常見的“完成”問題而生的。DoD 本身並不複雜，它就是告訴我們怎樣算是完成了，儘量減少因為歧義造成的各種浪費。

既然 DoD 是一個彌補理解差異的做法，那麼它就應該在人與人的協同工作中起作用。其中，最常見的做法是在團隊中確定好 DoD。比如：

特性開發完成，表示開發人員經過了需求澄清、功能設計、編寫程式碼、單元測試，透過了測試人員的驗收，確保程式碼處於一個可部署的狀態，相關文件已經編寫完畢。

開發完成，表示開發人員編寫好功能程式碼，編寫好單元測試程式碼，編寫好整合測試程式碼，測試可以透過，程式碼透過了程式碼風格檢查、測試覆蓋率檢查。

大家都是聰明人，一旦 DoD 確定好了，誰該做什麼事就一目瞭然了。

• DoD 是一個清單，清單是一個個的檢查項，用來檢查我們的工作完成情況。DoD 的檢查項，就是我們開發產品所需的一系列有價值的活動。比如：編寫程式碼、編寫測試程式碼、透過測試人員驗收等。

• DoD 是團隊成員間彼此彙報的一種機制。別把“彙報”想複雜了，最簡單的彙報就是說一句“這個功能做完了”。當我們有了 DoD，做事便只有兩種狀態，即“ 做完”和“沒做完 ”，根本沒有 80% 做完的說法。

• DoD 的檢查項應該是實際可檢查的：你說程式碼寫好了，程式碼在哪裡；你說測試覆蓋率達標了，怎麼看到；你說你功能做好了，演示一下。

在前面的討論中，我們所說的 DoD 只是從個人層面入手。在團隊層面，我們也可以定義 DoD，比如：

• 某個功能的 DoD，比如：這個功能特性已經開發完成，經過產品負責人的驗收，處於可部署的狀態。

• 一個迭代的 DoD，比如：這個迭代規劃的所有功能已經完成。

• 一次釋出的 DoD，比如，整個軟體處於可釋出狀態，上線計劃已經明確。

精益創業：驗證產品特性的思考框架

精益創業提出“ 開發（build）- 測量（measure）- 認知（learn） ”這樣一個反饋迴圈和最小可行產品的概念。

當你有了一個新的想法（idea）時，就把想法開發成產品（code）投入市場，然後，收集資料（data）獲取反饋，看看前面的想法是不是靠譜。無非得到兩種結果：好想法繼續加強、不靠譜的想法丟掉算了。不管是哪種結果，你都會產生新的想法，再進入到下一個迴圈裡。在這個反饋迴圈中，你所獲得的認知是最重要的，因為它是經過驗證的。

我們能夠接觸到的大多數產品都可以放在這個框架內思考 。當產品經理要做一個新產品或是產品的一個新特性，我們就可以用精益創業的這幾個概念來檢驗一下產品經理是否想清楚。

比如，你要做這個產品特性，你要驗證的東西是什麼呢？他要驗證的目標是否有資料可以度量呢？要解決的這個問題是不是當前最重要的事情，是否還有其他更重要的問題呢？如果這些問題得到肯定的答覆，那麼驗證這個目標是否有更簡單的解決方案，是不是一定要透過開發一個產品特性來實現。

任務分解馬斯克的任務分解

特斯拉的創始人伊隆·馬斯克（Elon Musk）同時還建立了太空探索公司 SpaceX。SpaceX 有一個目標是，送 100 萬人上火星。美國政府曾經算過一筆賬，把一個人送上火星，以現有技術是可行的，但需花費 100 億美金。如果送 100 萬人上火星就要 1 萬萬億，這筆錢相當於美國 500 年的 GDP，貴到連美國政府都無法負擔。

馬斯克怎麼解決這個問題呢？他的第一步是準備把人均費用降到 50 萬美元，相當於一個人在地球上房子的錢。把原來的 100 億降到 50 萬，降低 2 萬倍即可。

當然，降低 2 萬倍依然是一個聽起來很遙遠的目標。關注點來了，馬斯克的第二步是，把 2 萬分解成“20×10×100”，這是一道簡單的數學題，也是馬斯克三個重點努力的方向。

“20”：現在的火星飛船一次只能坐 5 個人，馬斯克打算把火箭造大一點，一次坐 100 人，這樣，就等於把成本降低 20 倍。如果你關注新聞的話，SpaceX 確實在進行這方面的嘗試。

“10”：馬斯克認為自己是私營公司，效率高，成本可以降到 1/10。事實上，SpaceX 的成本目前已經降到了同行的 1/5。

最後的 100 是什麼呢？就是回收可重複使用的火箭。如果這個目標能實現，發射火箭的成本就只有燃料成本，這也就是我們頻頻看到 SpaceX 試飛火箭新聞的原因。

這麼算下來，你是不是覺得馬斯克的目標不像最開始聽到那樣不靠譜了呢？正是透過將宏大目標進行任務分解，馬斯克才能將一個看似不著邊際的目標向前推進。

微操作

在ThoughtWorks 工作時，我的 Sponsor 是 ThoughtWorks 現任 CEO 郭曉（Sponsor，類似於工廠裡師傅帶徒弟的關係），他也是寫程式碼出身的。他和我講過他和 Wiki 的發明者 Ward Cunningham 一起結對程式設計的場景。

Ward 每天拿到一個需求，並不急於寫程式碼，而是和郭曉一起做任務分解，分解到每個任務都很清晰之後，一個個任務完成就好了。當時郭曉雖然覺得工作很緊張，但思路卻非常清晰。有時，他也很奇怪，因為在開始工作之前，他會覺得那個問題非常難以解決，結果一路分解下來，每一步都是清晰的，也沒遇到什麼困難就完成了。

任務分解是個好習慣，但想要掌握好它，大量的練習是必須的。我自己也著實花不少時間進行練習。隨著我的練習增多， 我越發理解任務分解的關鍵在於“小” 。小到什麼程度呢？有時甚至可以小到你認為這件事不值得成為一件獨立的事，比如，升級一個依賴的版本，做一次變數改名。這樣做好處就是，它保證了我可以隨時停下來。

我曾讀到過一個關於著名高爾夫球手“老虎”伍茲的故事。高爾夫球手在打球的時候，可能會受到一些外界干擾，一般情況下還好，如果他已經開始揮杆，這時候受到了干擾，一般選手肯定是繼續把杆揮下去，但通常結果是打得不理想。而伍茲遇到這種情況，他會停下來，重新做揮杆的動作，保證了每一杆的標準。

伍茲能停下來，固然是經過了大量的練習，但還有一個關鍵在於，對於別人而言，揮杆擊球是一個動作，必須一氣呵成，而對伍茲來說，這個動作是由若干小動作組成，他只不過是剛好完成了某個小動作，而沒有做下一個小動作而已。換句話說，大家同樣都是完成一個原子操作，只不過，伍茲的原子操作比其他人的原子操作小得多。

如果對程式設計師感興趣的，想學習web前端開發的朋友，可以加web前端學習秋秋裙767，web前端中間的數字是273，web前端最後是102 。7年全棧工程師，根據這些年從事開發經驗，整理了一份最適合2019年學習的web前端乾貨，web前端的大型網際網路技術教學影片，還有一份前端零基礎教程免費分享給大家。有想學習web前端的，或是轉行，或是大學生，還有工作中想提升自己能力的，歡迎大家加入，這裡是前端學習者的集中地