開發者的效率目標

在實際開發過程中，往往存在兩種截然相反的行為傾向：

以時間換效率

以效率換時間

這兩種行為模式，在固定一天時間內，達到同樣的生產力，可以靠低效率、堆時間的方式，和另一種高效率，節省時間的方式。

大多數人都知道提高效率，但是，提高效率是目的，是手段，如果僅僅知道提高效率，還是沒找到落腳點。

從大的方面，可以分為投入和產出兩個方面考慮。

投入意味著成本，對於開發者來說，我們這裡主要指的是時間成本。

節省時間成本需要有幾個意識：

質量意識，要求開發者開發過程中，注重開發的質量，把握質量與工期的平衡，以達到在總工期中投入時間的最小化。在軟體工程化中，問題發現的越靠後，付出的代價越大，甚至會浪費別人的時間來排查，而這些時間是彌補之前的過失，本來可以用來產生更大價值的。

服務意識，要求開發者服務自己和服務別人，在開發中，注意積累重要的文件，編寫方便的測試**，服務未來會遺忘當下的自己，以及方便其他開發者合作。

產出，就是指的創造價值。

為客戶創造價值，以及為長期主義堅持的事情創造價值。

一次編寫，長期收益，是最好的模式。

模組要控制輸入輸出。

乙個模組，要保證輸出正確，並且獲取輸出的資料，由該模組owner 負責封裝介面api，編譯成庫，並且模組接收測試應用程式同時寫好。這樣保證了兩點：

輸出的可靠性，可靠的輸出是下游模組除錯效率的保證；

測試程式，和封裝的接收側lib庫，方便下游直接快速應用；下游快了，上有慢了。開發任務在上下游間再分配，上游保證輸出正確和提供呼叫測試程式和庫，將聯調時間壓縮到最短。

遇到問題，測試程式可以迅速定位錯誤出現在上游還是下游，節省了大量定位問題的時間。

重新分配開發內容和組織形式後，開發變快，持續收益。

接手別人的程式來除錯，一定要自己寫測試程式，有時候重寫都比用乙個未經除錯的混亂和錯誤百出的**快很多倍。無論何時，自己的測試程式才是讓自己快速定位問題和前進的法寶。基於自己的測試程式重寫，是最快的捷徑，反而用現成的，更慢。

用到自己的庫時，出問題，注意寫測試**，對比系統預設的庫和自己改過的庫，判斷問題出在**。