軟件熵：軟件開發中推倒重來的過程就是軟件熵不斷增長的過程

    每個軟件項目的第一個版本都很漂亮。新項目從零開始，全部的內容都是新開發的。由於全新開發，就意味着沒有歷史負擔的問題。第一個版本的BUG很是少，固然，程序員也盡力作到最好。這意味着，在開發人員的眼中，第一個版本能夠算是完美：代碼漂亮、設計良好、架構優秀。

    第一個版本一旦發佈，就會有人發現BUG，並公佈出來，這些BUG都須要被修復。這時，第二個版本的起點就要比第一個版本高得多。第二個版本並不是從零開始，而是創建在全部問題的基礎上。並且，對於大部分的軟件項目來講，每每沒有足夠的資源和時間把事情作得很是完美。因此對新版本的調整和修改就沒有第一個版本那樣漂亮和整潔。

    這樣就會在後續版本中不斷地增長軟件熵，代碼變得愈來愈難以維護。負責維護的開發人員開始每天抱怨，特別是那些代碼原做者已經聯繫不上的狀況下，抱怨就更加嚴重。

    終於有一天，項目會處於一個特定的階段，此時，開發人員只能說：「別去動這個軟件了！」。代碼猶如一團亂麻，任何改變都有可能讓某些功能沒法正常運行。問題愈來愈大，最後管理層獲得的信息就是這個軟件病入膏肓了，他們也許會決定從新開發一個軟件。

    頗有可能，開發新的版本所用時間會比原計劃的時間要多得多。並且功能也可能比老版本還要少。但這個新版本將會很是漂亮和整潔。很明顯，由於這個版本又是從零開始了。從設計角度來講，不會有什麼問題。這個版本又像第一個版本同樣的優雅、漂亮。如今終於達成咱們預計的目標了。

    事實上，出如今第一個版本中的問題也會一樣出如今最新重寫的這個版本中，代碼會再一次地變成一團亂麻，須要有人去維護，會引入各類修改方法，全部出如今第一個版本中的問題都會一一重現。直到有人痛下決心，想從根本上解決問題時，又會出現前面的那種推倒重寫的事情。雖然從新開發新的版本的確付出了很多努力，但每一次咱們都會從新回到起點，重犯以前的錯誤。這種努力就是白費。

    對於推倒重來的這種作法，咱們每每是抱着會有更好結果的想法去爲之，但最終卻每每是一樣的錯誤一犯再犯。因此沒有任何理由支持咱們這樣從頭開始來作一件事。若是想要一個更好的結果，就須要改變開發的方式。只有改變了開發方式，纔可能有更好的結果。

    總而言之，要學會使用增量迭代、小步前進的敏捷開發方法！人們須要軟件加以改進，但改進時引入的傷害也應該最小化，特別是要避免只爲增長功能而不顧設計走捷徑使用非正常手段的狀況。

 

 

 

 

 

 

 

參考書籍：

英文原名：Practical API Design: Confessions of a Java Framework Architect

中文譯名：軟件框架設計的藝術