前言：软件在设计阶段如果能够多考虑一些后续的维护工作，显然是非常棒的。然而对于现阶段的我，或者很多程序员来说，未雨绸缪有很大难度，我们往往即使已经下雨了，也依然无法把窗户关紧，那么如果你想得到一些指导的话，请随我来，看看我能否品出一些味道来。
没有什么是永恒的，除了变化。
普遍的做法是，选择一个方案，试试看；如果失败了，没关系，再试试别的。不管怎么样，重要的是去尝试。
我觉得书中提供的这两个观点非常的棒，首先，任何事都不可能一成不变，敏捷宣言也提倡我们要拥抱变化。其次，在解决问题的时候，就是要不断的尝试，这个方案没有解决问题，就去尝试另外一个，直到你想不到别的办法，你再去求救别人。
实验性工厂和增大规模
现如今，很少有公司敢把没有经过beta测试的产品直接上线运行，那带来的后果是不可估量的。
当你完成了代码测试，就觉得程序万无一失，着急上线的话，往往打击是惨痛的。就如同诸葛亮认为马谡熟读兵法再加上跟随诸葛亮多年，派他去守街亭，结果被马谡的昏招教训的惨痛。
在好不容易开发出第一版产品后，即使它非常的差，我似乎很眷恋它，无法丢弃它。然而更好的做法是，在开发第一版产品的时候，要考虑在日后变更它，甚至丢弃它的可能性，至少能够对一些关键点留下后路。
唯一不变的就是变化本身
我个人就非常的讨厌一个方案确定下来后，再因为用户的需求变化而做出调整，从思想的源处，我似乎还没有接受这种观念，说实话， 我就是厌恶变化。
但是现实就是喜欢开玩笑，用户的需求会变化，软件的技术会变化，你的能力会变化，如果你在设计之初没有考虑到变化，那么当你不得不做出改变的时候，将会十分的痛苦。
举个例子来说，银行流水号，一般情况下，年月日时分秒+4位随机数就够用了，于是你可能把字段设计为long型，字段长度为18位。如果你这样做的话，我告诉你，你会后悔的，你最好设计为string类型的25位长度的字段，这样才能拥抱变化。
为变更计划系统
的确，变更就想小孩子的脸，如果你不准备好糖果或者奶水，那么一旦小孩子变脸，你将无法再控制他。那么对于软件设计，我们能做些什么呢？
为产品迭代建立合适的周期和版本。
采用更高级的软件框架和开源技术。
为变更计划组织架构
当只有一个新野的时候，刘关张没有选择的就要驻扎在一起；而当有了徐州和小沛，三人就要分开，但至少有两人还在一起；然后当有了荆州，并且了双线进军西川的时候，三人就要完全分开。而在此时，关羽要做的不仅仅是守荆州，同时还要单刀去赴会；张飞不仅仅要葭萌关大战马超，还要能使用计谋义释严颜；彼此在武力和智力上都要经得住考验。
那么在应对软件变更过程中，组织可以做些什么来应对呢？
技术人员和管理人员具有互换性。（目前的我似乎已经习惯于在更多的角色定位中穿梭）
在管理线和技术线上设置具有相同薪水的不同阶层，同时树立各自的威信。（每朝每代，文官和武馆都会站在不同的列队，然而层级是一致的，这样就确保文武百官各司其职，并且能够相互依赖）
当然最好的就是，每个人都能文武双全，像周瑜（三国演义是为了衬托出诸葛亮的牛，但事实上周瑜在智力和武力上都属于顶级水准）一样，这样可以使结果在面对变化的时候进行更快捷的调整。
前进两步，后退一步
对于广泛使用的程序，维护成本通常是开发成本的40%或更多。
缺陷修复总会以固定（20%-50%）的几率引入bug。
总体上能够前进一步，已经实属难得。结合我自身的经验就知道，在现实的软件开发以及维护中，每当修复一个当前问题时，总会有一定几率引入新的bug，我之前总是怪罪自己的不小心，但是后来我知道，能够快速解决问题才是王道。即使像诸葛亮也无法预知在他进行七星灯工作的时候，魏延在最后关头摆了他一刀。
前进一步，后退一步
用在修复原有设计上瑕疵的工作量越来越少，而早期维护活动本身引起的漏洞修复工作越来越多。
这个现象也普遍的发生，有些产品无论再怎么改进，他的水平也就维持在那样一个高度，不会发生质变。
那么最好的方式是什么呢，那就是重新再来一个。就如同中国的道路一样，没过一段时间，就要让人忍受马路的修修补补，然而并不能从根本上解决问题，一段时间过后，另外一处要重新打上补丁。那么如何解决呢，那就是放弃那个豆腐渣的公路吧，重新搭建一条新马路。
