深入了解业务，最好的设计就出自你的手。
强调对业务的了解对程序设计尤为重要。
放弃修改历史的想法吧，一个项目的基本路径应该是这样的：项目开发、重构、测试、投产、运维，其中的重构可以对原有的设计和代码进行修改，运维尽量减少对原有代码的修改，保持历史代码的纯洁性，提高系统的稳定性。
在维护的时候尽量通过继承、实现等手段实现，尽量不要修改原有代码。这样做的前提是顶层抽象的很完美，如果抽象不是很完美呢？1、考虑重构（风险比较大，但是可以彻底解决问题）。2、考虑通过继承原有抽象以补充原有抽象的不足。
一个方法的测试方法一般不少于3种，为什么呢？首先是正常的业务逻辑要保证测试到，其次是边界条件要测试到，然后是异常要测试到。
测试的时候做到全覆盖还是很重要的。
万物皆对象，我们需要把所有的事物都抽象成对象，然后针对对象进行操作，但是万物皆运动，有运动就有变化，有变化就要有策略去应对，怎么快速应对呢？这就需要在设计之初考虑到所有可能变化的因素，然后留下接口，等待“可能”转变为“现实”。
说来说去设计的终极目标还是应对变化，应对变化就要求先识别出变化，这就是需要在设计之初考虑到所有可能变化的因素的原因。这个需要大量的项目经验和对业务的深入了解了。
抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放，其包含三层含义：第一，通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；第二，参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；第三，抽象层尽量保持稳定，一旦确定即不允许修改。
一个接口或抽象类就可以应对一种变化，这也许就是接口的本质吧。前两点好理解，第三点对抽象能力要求很高，要求定义接口的时候要非常慎重。如何才能保证抽象层的稳定呢？还得基于对业务的深入理解和丰富的项目经验吧！
在实践中过程中，架构师或项目经理一旦发现有发生变化的可能，或者变化曾经发生过，则需要考虑现有的架构是否可以轻松地实现这一变化。架构师设计一套系统不仅要符合现有的需求，还要适应可能发生的变化，这才是一个优良的架构。
读《设计模式之禅》感悟
本文出自 “埃文” 博客，请务必保留此出处http://wenshengzhu.blog.51cto.com/5151285/1972472
原文地址：http://wenshengzhu.blog.51cto.com/5151285/1972472
