程序員是一個忙碌的職業,與這個職業聯繫在一塊兒的詞兒,一般是忙碌、加班、熬夜、過勞、亞健康……當忙碌成爲了主旋律,「高效」一詞就天然浮出了水面。程序員
但是,程序員工做效率是由編程能力決定的嗎?答案是「未必」。編程
這些年,我一直在研究一件事兒:爲何那些大師級程序員,能夠兼顧 N 倍於通常人的工做,還有條不紊?他們究竟用了什麼工做法?根據個人觀察與總結,他們每每繞不開下面四個工做原則。框架
下面,就給你們先介紹前兩個工做原則。ide
以終爲始DoD單元測試
DoD(Definition of Done,完成的定義),從名字便不難看出,它就是爲了解決軟件開發中常見的「完成」問題而生的。DoD 自己並不複雜,它就是告訴咱們怎樣算是完成了,儘可能減小由於歧義形成的各類浪費。測試
既然 DoD 是一個彌補理解差別的作法,那麼它就應該在人與人的協同工做中起做用。其中,最多見的作法是在團隊中肯定好 DoD。好比:ui
特性開發完成,表示開發人員通過了需求澄清、功能設計、編寫代碼、單元測試,經過了測試人員的驗收,確保代碼處於一個可部署的狀態,相關文檔已經編寫完畢。開發完成,表示開發人員編寫好功能代碼,編寫好單元測試代碼,編寫好集成測試代碼,測試能夠經過,代碼經過了代碼風格檢查、測試覆蓋率檢查。idea
你們都是聰明人,一旦 DoD 肯定好了,誰該作什麼事就一目瞭然了。spa
在前面的討論中,咱們所說的 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 天天拿到一個需求,並不急於寫代碼,而是和郭曉一塊兒作任務分解,分解到每一個任務都很清晰以後,一個個任務完成就行了。當時郭曉雖然以爲工做很緊張,但思路卻很是清晰。有時,他也很奇怪,由於在開始工做以前,他會以爲那個問題很是難以解決,結果一路分解下來,每一步都是清晰的,也沒遇到什麼困難就完成了。
任務分解是個好習慣,但想要掌握好它,大量的練習是必須的。我本身也着實花很多時間進行練習。隨着個人練習增多,我愈加理解任務分解的關鍵在於「小」。小到什麼程度呢?有時甚至能夠小到你認爲這件事不值得成爲一件獨立的事,好比,升級一個依賴的版本,作一次變量更名。這樣作好處就是,它保證了我能夠隨時停下來。
我曾讀到過一個關於著名高爾夫球手「老虎」伍茲的故事。高爾夫球手在打球的時候,可能會受到一些外界干擾,通常狀況下還好,若是他已經開始揮杆,這時候受到了干擾,通常選手確定是繼續把杆揮下去,但一般結果是打得不理想。而伍茲遇到這種狀況,他會停下來,從新作揮杆的動做,保證了每一杆的標準。
伍茲能停下來,當然是通過了大量的練習,但還有一個關鍵在於,對於別人而言,揮杆擊球是一個動做,必須一鼓作氣,而對伍茲來講,這個動做是由若干小動做組成,他只不過是恰好完成了某個小動做,而沒有作下一個小動做而已。換句話說,你們一樣都是完成一個原子操做,只不過,伍茲的原子操做比其餘人的原子操做小得多。