软件熵：软件开发中推倒重来的过程就是软件熵不断增长的过程

    每个软件项目的第一个版本都很漂亮。新项目从零开始，全部的内容都是新开发的。由于全新开发，就意味着没有历史负担的问题。第一个版本的BUG很是少，固然，程序员也尽力作到最好。这意味着，在开发人员的眼中，第一个版本能够算是完美：代码漂亮、设计良好、架构优秀。

    第一个版本一旦发布，就会有人发现BUG，并公布出来，这些BUG都须要被修复。这时，第二个版本的起点就要比第一个版本高得多。第二个版本并不是从零开始，而是创建在全部问题的基础上。并且，对于大部分的软件项目来讲，每每没有足够的资源和时间把事情作得很是完美。因此对新版本的调整和修改就没有第一个版本那样漂亮和整洁。

    这样就会在后续版本中不断地增长软件熵，代码变得愈来愈难以维护。负责维护的开发人员开始每天抱怨，特别是那些代码原做者已经联系不上的状况下，抱怨就更加严重。

    终于有一天，项目会处于一个特定的阶段，此时，开发人员只能说：“别去动这个软件了！”。代码犹如一团乱麻，任何改变都有可能让某些功能没法正常运行。问题愈来愈大，最后管理层获得的信息就是这个软件病入膏肓了，他们也许会决定从新开发一个软件。

    颇有可能，开发新的版本所用时间会比原计划的时间要多得多。并且功能也可能比老版本还要少。但这个新版本将会很是漂亮和整洁。很明显，由于这个版本又是从零开始了。从设计角度来讲，不会有什么问题。这个版本又像第一个版本同样的优雅、漂亮。如今终于达成咱们预计的目标了。

    事实上，出如今第一个版本中的问题也会一样出如今最新重写的这个版本中，代码会再一次地变成一团乱麻，须要有人去维护，会引入各类修改方法，全部出如今第一个版本中的问题都会一一重现。直到有人痛下决心，想从根本上解决问题时，又会出现前面的那种推倒重写的事情。虽然从新开发新的版本的确付出了很多努力，但每一次咱们都会从新回到起点，重犯以前的错误。这种努力就是白费。

    对于推倒重来的这种作法，咱们每每是抱着会有更好结果的想法去为之，但最终却每每是一样的错误一犯再犯。因此没有任何理由支持咱们这样从头开始来作一件事。若是想要一个更好的结果，就须要改变开发的方式。只有改变了开发方式，才可能有更好的结果。

    总而言之，要学会使用增量迭代、小步前进的敏捷开发方法！人们须要软件加以改进，但改进时引入的伤害也应该最小化，特别是要避免只为增长功能而不顾设计走捷径使用非正常手段的状况。

 

 

 

 

 

 

 

参考书籍：

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

中文译名：软件框架设计的艺术