不重視tdd與code review的代價。近些年來，越來越多的人開始向我諮詢測試驅動開發(tdd)的好處。所謂 tdd，就是在將**進行部署之前，利用各種自動化測試來確保**能夠正常工作。在進行測試的時候，你需要尋找測試失敗的地方，然後不斷修改，必要的時候還需要對**進行重寫。
實踐證明，tdd 是軟體開發過程中必不可少的一環。而且它還能夠幫助企業和員工節省大量的時間。
你需要知道的是，tdd 能幫你減少 40-80% 的**錯誤修復時間。要知道，生產**中的 bug 越多，你所需要付出的維護成本就越高。
bm system sciences institute 的研究顯示，在生產階段修復**的時間，是在設計階段修復**時間的 100 倍以上，是部署階段修復**世界的 15 倍以上。
利用這組資料，我們來看看如果不使用 tdd，我們需要多花多少時間成本。如果沒有 tdd，你的專案在部署階段就需要花費 1000 個小時的時間，其中還沒有包括維護時間成本：
也就是說，tdd 能夠幫你省下 623 個小時的時間，假如你的工程團隊有 4 個人，這意味著能幫你省下 1 乙個月的開發時間。美國開發者的平均年薪為 9.5 萬美元，再算上這些人的福利，tdd 能幫你省下 3.7 萬美元。
當然，這只是粗略的計算，tdd 能幫你省下多少成本，還應取決於很多其他因素。
但是 tdd 的重要程度依然可見一斑，它的確能夠幫你節省下大量的時間和經濟成本。
code review 的作用
和 tdd 一樣，code review 也有著類似的作用。事實上，一些研究顯示，code review 甚至比 tdd 更能幫你節省成本。1988 年的一項研究顯示，一小時的 code review，能幫你在後期節省 33 個小時的**維護時間。
這個數字看上去很驚人吧?但是我個人認為，在尋找 bug 方面，code review 並沒有自動化工具好用。那麼 code review 究竟有什麼用處呢?
知識分享。在引入 code review 之後，你的團隊會自動開始在彼此之間分享各自的知識、經驗和工作方式。這樣一來團隊中的每個人都會開始更快的成長，初期工程師不斷的向高階工程師進行學習，同時團隊也開始不斷成長。對於企業來說，擁有乙個優秀的工程團隊，是企業最重要的資產之一。
開發者最怕打擾
修復 bug 需要我們付出什麼樣的成本?在生產階段修復**，實際上其成本要遠高於在開發階段修復 bug，而且會讓開發者非常頭疼。
在生產階段發現 bug 之後，開發者必須要放下手頭的工作，去解決這個 bug。換句話說，開發者本來正沉浸於一項工作當中，但是不得不跳出當下的情境 ，進入 bug 修復情境 。在修復了 bug 之後，再跳回到之前的情境中。
切換一次情境大約需要 20 分鐘的時間。而且更糟的是，在發現了乙個 bug 之後，很多時候意味著開發者此前做的工作都會受到這個 bug 的影響，他們很多的工作都需要推到重來。microsoft research 的研究顯示，在受到打擾之後，開發者需要花費預期中雙倍的時間來完成這個任務，而且出錯的機率也會加倍。
讓開發者去處理多工，這絕對不是乙個好主意。要想提高他們的工作效率，那就應該讓他們專注於一件事情。
總結
如果有人對你說他們沒有時間或是預算使用 tdd 和 code review 的時候，你不妨給他講講 tdd 和 code review 能幫他省下多少時間和經濟成本。
不重視TDD與Code Review的代價
不重視tdd與code review的代價。英文原文 the outrageous cost of skipping tdd code reviews 近些年來，越來越多的人開始向我諮詢測試驅動開發 tdd 的好處。所謂 tdd，就是在將 進行部署之前，利用各種自動化測試來確保 能夠正常工作。在進行...
並非我們不重視理想
做乙個努力的人 有一次，在我參加的乙個晚會上，主持人問乙個小男孩 你長大以後要做什麼樣的人?孩子看看我們這些企業家，然後說 做企業家。在場的人忽地笑著鼓起了掌。我也拍了拍手，但聽著並不舒服。我想，這孩子對於企業究竟知道多少呢?他是不是因為當著我們的麵才說要當企業家的呢?他是不是受了大人的影響，以為企...
不重視小C打屁屁
在pdca中，c 往往是容易忽視的環節，這個小c有些時候還真是很致命，很多時候總是想當然的認為自己做的不錯，就忽略了這個環節，而實際情況恰恰與你預計的相反，而且很現實，比如 1 程式修改完了，自認為沒有問題，不需要測試了，但是恰恰就有個大bug。2 命令下達完了，往往認為下屬可以理解了，但是實際的執...