?? 代碼會生銹嗎？這真是一個很奇怪的問題，代碼怎么會生銹呢？但是現在的許多軟件企業，卻總認為代碼放久了就會發霉，會生銹，因此每次發布的新版本總拋棄了原來所有的代碼從頭來過。這種做法真的可取嗎？我們且不說這么做要浪費多少人力物力（反正公司有的是錢 really？但為什么工資只開這么一點點，配的電腦也這么爛），就僅僅從新版本的質量來講，也不見得盡如人意。誰能夠保證新版本的核心人員與原來版本是同一批人，那么又怎么來保證原來的“經驗積累”能夠在新版本中發揮作用。另外，老版本的代碼多是經過項目實踐來檢驗的，它們身上可能帶著修復bug后，留下的傷疤，但是至少它已經痊愈
了，他已經成為了一名經歷過戰場洗禮的戰士。而新版本呢，好比是在軍校學習的學生，它們可進行了更為先進的戰略戰術的學習（一些更先進的技術）但是，遺憾的是他們從來沒有在戰場上真槍實彈的打過仗，（在項目中許多新技術的應用往往是程序員邊學邊用的，當然，這也是軟件行業的一個特點）因此能否成為合格的戰士還需要經過實戰（項目）的考驗，而不僅僅是考試（測試人員）的成績。如果我們把一些戰斗經驗豐富的老戰士，進一步培訓（對老版本進行修復，重構）我想他們的戰斗力可能會遠遠超過這些新兵？
?? 但是為什么這么多的企業，都會不約而同的選擇重新編寫代碼呢，我想很可能是那些程序員在作怪（呵呵，不好意思我也是一個程序員，在這里只是就事論事 不敢含有任何貶低咱程序員的意思）。程序員總是不停的在抱怨，原來的代碼事如何如何的亂，幾頁的代碼竟然沒有任何注釋，許許多多的代碼我竟然不知道做什么用的，讓我修改，我還不如重寫一遍呢？這是發生在程序員修改別人寫的代碼時，時常會發的牢騷。 原來的代碼真的真么糟嗎，其實并不盡然。那寫你看起來一團糟的代碼，也許就是修改某個
bug 時留下的傷疤，如果從頭寫一段新的代碼，誰能保證你的代碼沒有原來那bug呢？其實我們可以采用很多重構的方法來解決，如設計模式的開閉原則，就可以很好的規避這一類問題。
? 因此我認為，一個企業不要總是頻繁的發布新版本，只有可以明確的指出現有版本已經滿足不了市場的需求了，我們才需要重新規劃。我們需要明確，我們當前最需要做的是對現有版本修修補補，使之不斷完善，不斷健壯。君不見，網景的netscape 和borland 的dbasde就是前車之鑒嗎？
?
?? 注：網景的netscape 因新版本重寫代碼，整整用了3年的時間，其市場份額從80％ 降到了20％
?????? borland 從些Arago（dbase的前身） 也把市場白白的讓給了 access