代码会生锈吗？这真是一个很奇怪的问题，代码怎么会生锈呢？但是现在的许多软件企业，却总认为代码放久了就会发霉，会生锈，因此每次发布的新版本总抛弃了原来所有的代码从头来过。这种做法真的可取吗？我们且不说这么做要浪费多少人力物力（反正公司有的是钱 really？但为什么工资只开这么一点点，配的电脑也这么烂），就仅仅从新版本的质量来讲，也不见得尽如人意。谁能够保证新版本的核心人员与原来版本是同一批人，那么又怎么来保证原来的“经验积累”能够在新版本中发挥作用。另外，老版本的代码多是经过项目实践来检验的，它们身上可能带着修复bug后，留下的伤疤，但是至少它已经痊愈
了，他已经成为了一名经历过战场洗礼的战士。而新版本呢，好比是在军校学习的学生，它们可进行了更为先进的战略战术的学习（一些更先进的技术）但是，遗憾的是他们从来没有在战场上真枪实弹的打过仗，（在项目中许多新技术的应用往往是程序员边学边用的，当然，这也是软件行业的一个特点）因此能否成为合格的战士还需要经过实战（项目）的考验，而不仅仅是考试（测试人员）的成绩。如果我们把一些战斗经验丰富的老战士，进一步培训（对老版本进行修复，重构）我想他们的战斗力可能会远远超过这些新兵？
但是为什么这么多的企业，都会不约而同的选择重新编写代码呢，我想很可能是那些程序员在作怪（呵呵，不好意思我也是一个程序员，在这里只是就事论事 不敢含有任何贬低咱程序员的意思）。程序员总是不停的在抱怨，原来的代码事如何如何的乱，几页的代码竟然没有任何注释，许许多多的代码我竟然不知道做什么用的，让我修改，我还不如重写一遍呢？这是发生在程序员修改别人写的代码时，时常会发的牢骚。 原来的代码真的真么糟吗，其实并不尽然。那写你看起来一团糟的代码，也许就是修改某个
bug 时留下的伤疤，如果从头写一段新的代码，谁能保证你的代码没有原来那bug呢？其实我们可以采用很多重构的方法来解决，如设计模式的开闭原则，就可以很好的规避这一类问题。
因此我认为，一个企业不要总是频繁的发布新版本，只有可以明确的指出现有版本已经满足不了市场的需求了，我们才需要重新规划。我们需要明确，我们当前最需要做的是对现有版本修修补补，使之不断完善，不断健壮。君不见，网景的netscape 和borland 的dbasde就是前车之鉴吗？
注：网景的netscape 因新版本重写代码，整整用了3年的时间，其市场份额从80％ 降到了20％
borland 从些Arago（dbase的前身） 也把市场白白的让给了 access