軟體開發，小步真能快跑嗎？

每天讀一篇一線開發者原創好文

作者簡介

作者樂攀是非常優秀的程序員，有10多年的程序設計和開發經驗，近年來致力于敏捷軟體開發管理和技術實踐的落地。

本文主要論證一個理念：哪怕僅僅只考慮軟體正確性所付出的時間代價，小步快跑的效率也是優於大幹快上的。希望能給一線程序員和開發經理一些啟發。

軟體行業似乎形成了約定俗成的理念：bug發現得越早，修復成本越低；發現越晚，修復成本越高。

這個結論是否真的成立？本文將對此進行討論。根據金字塔原理，先拋出結論，是真的。

讓我們來考慮這樣一個典型需求的實現過程：軟體接受一個矩陣輸入，進行一系列矩陣變換，最後輸出變換後的結果（仍然是個矩陣）。其數學表達為Yn = F1（F2（F3（……Fn（x）……）））。此過程中，我們只考慮正確性，而不對其它方面做過多研究。

在開發階段，它可以被劃分為多個過程模塊，每個模塊規模大致相當，模塊和模塊之間只傳遞輸入輸出數據，首尾相接。顯而易見，只要一個模塊實現有問題，則最終輸出都是不正確的。小步快跑的開發方式，即開發一個，驗證一個，集成一個，由於之前的假設，全部模塊集成到一塊以後，必然是一步到位。大幹快上的開發方式，即先進行全部模塊的開發，最後再集成到一塊進行質量保證活動。究竟哪種開發方式，開發時間會更短？

選擇合適的規模1（和團隊開發水平息息相關），來滿足以下假設

假設1，在規模1及以下，通過1次反饋就能保證其正確性，所需要的時間是：t開發+t質量保證，t質量保證=t反饋

假設2，在規模1以上，如不經過反饋，則必然出現至少1個bug

假設3，在規模1以上，一旦出bug，只能先通過二分查找法，把bug定位到某個規模為1的軟體模塊，才能解決

有以上假設後，不難得出以下推論，如果規模為N（N > 1），兩種開發方式的時間對比：

小步快跑：N *（t開發+t質量保證）

大幹快上：N *t開發+log2N*N*t質量保證/2

在開發上面花的時間，兩者是一樣的，都是N*t開發

在質量修復方面，小步快跑總共花費的時間是N*t質量保證，時間複雜度是O(N)

大幹快上因為到了最後總還是會出1個bug，在二分查找法方面，需要進行log2N次反饋，才能定位bug，因為bug可能出在任意一個模塊，平均下來，每次的反饋時長是N*t質量保證/2。則花在質量保證方面的時間是log2N*N*t質量保證/2，其時間複雜度是O(N*log2N)

結論很清晰，大幹快上確實不如小步快跑，除了特殊情況：N

姑且認為開發水平足夠高，在不做任何的質量保障活動的前提下，每1000行的代碼有3個bug（這在業界已經是非常恐怖的數據了）。那麼300行的規模，或者可以滿足假設2，不可能再大了。則以一個10萬行規模的軟體來看，其N值為333。哪怕只出1個bug，大幹快上在質量保證方面花費的時間已經是小步快跑的4倍以上！

這已經是對大幹快上非常偏袒了，首先，如此規模的軟體，不可能只有1個bug；其次，編碼水平已經是行業內數一數二的；再者，模塊組織相當合理，二分查找法能發揮最大效用；最後，一次反饋就能解決bug，這也是非常理想化的，根本不敢想。

通過簡單推導，再次證明了本文開頭所述觀點的正確性。但為什麼還有那麼多技術團隊，願意大幹快上呢？原因無外乎幾點：

1、早期軟體規模不大，兩者區分不明顯，一直沒更新觀念；

2、由於各種原因，軟體難以被劃分為合適的規模；

3、可測試性不足，即使劃分，也沒法驗證；

4、進度逆排序，發現bug解決階段耗時多，則壓縮開發時間為bug解決爭取時間……

5、僥倖心理

由此導致的後果，依然還是技術團隊自己承擔。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！