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

標籤：des   style   http   color   os   io   使用   java   ar   

    每一個軟體項目的第一個版本都很漂亮。新項目從零開始，所有的內容都是新開發的。因為全新開發，就意味著沒有曆史負擔的問題。第一個版本的BUG非常少，當然，程式員也儘力做到最好。這意味著，在開發人員的眼中，第一個版本可以算是完美：代碼漂亮、設計良好、架構優秀。

    第一個版本一旦發布，就會有人發現BUG，並公布出來，這些BUG都需要被修複。這時，第二個版本的起點就要比第一個版本高得多。第二個版本並非從零開始，而是建立在所有問題的基礎上。而且，對於大部分的軟體項目來說，往往沒有足夠的資源和時間把事情做得非常完美。所以對新版本的調整和修改就沒有第一個版本那樣漂亮和整潔。

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

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

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

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

    對於推倒重來的這種做法，我們往往是抱著會有更好結果的想法去為之，但最終卻往往是同樣的錯誤一犯再犯。所以沒有任何理由支援我們這樣從頭開始來做一件事。如果想要一個更好的結果，就需要改變開發的方式。只有改變了開發方式，才可能有更好的結果。

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

 

 

 

 

 

 

 

參考書籍：

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

中文譯名：軟體架構設計的藝術 

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