客户端敏捷开发之道[一]:设计模式篇
正式参加工作已逾三年，打算把工作沉淀下来的方法论整理出来，以作纪念。思来想去，还是觉得用「敏捷之道」贯穿这个系列最为合适。由于每年新沉淀的方法论，是在以往的经验基础上总结的，因此本系列文章具有一定的前后依赖关系，建议按顺序阅读。
以前实习的时候，曾听一位前辈说过：“掌握设计模式，即是忘记模式”。如果您对这句话心存困惑，那也许本文读下去是值得的。
（一）设计模式到底在什么情况下使用？
在我们学生时期，无论是编程竞赛，还是编程作业，几乎没有感觉出设计模式的意义。而进入工作岗位后，又忽然间发现它的重要性，这是为什么？
其实区别只有一个，那就是：工作以后，我们的代码要不停的改，而学生时，作业提交了，就不用再改了。
当我们设计一个复用的组件时，「下一次」调用即可不用再重写。当我们生成一个基类时，「下一次」设计类似的方案，只需要写变化的部分。事实上，无论当我们使用哪种模式还是依据各种原则做开发时，本质上都是为了「下一次」改代码做准备。所以设计模式的目标是：当需求不停的变化时，让我们可以在原有代码上，更好的适应这些变化。当我们还在学生时期时，我们的代码一次开发，提交后不再修改，此时设计模式没有任何意义，我们也感觉不到任何意义，因为没有二次开发。而当我们进入工作时，需求迭代的压力骤然袭来，此时，熟练运用设计模式便成为了我们的基本功。
总结一下，设计模式的故事就是这一句：无变化，不设计，面向变化做设计。
（二）开放封闭原则，到底在讲些什么？
开放封闭原则是Bertrand Meyer在1988年提出的，原文如下：Software entities should be open for extension,but closed for modification。事实上，开放封闭原则可以覆盖很多设计模式，因此这里想以这个原则为例，探究设计模式原则到底在说什么。
事实上，开闭原则是一个科幻原则，因为无论使用什么模式来符合这条原则，都不可能完全不对原来的代码做修改，即使最符合这个原则的模式，至少也要插入一行代码（写这段话时，忽然想到用配置文件可以做到，不过不钻牛角尖，嗯）。所以，我对这个原则有另外一个理解：
少改少错，多改多错，不改不错。之所以要说开放封闭原则，其实是想借此说明这样一个道理：设计的原则，其实是告诉我们一定要改代码时，怎样改比较好。
（三）那些设计模式，到底在讲些什么？
先说结论：每一种设计模式都对应着一种变化。
由前面我们已经知道，设计模式是用于应对变化，而设计原则又告诉我们怎样应对变化，那么设计模式最终将告诉我们应对何种变化。
例如：当我们开发弹窗时，可以预见到弹窗会有多种样式，而他们的基本行为都是差不多的，未来还会开发出其它样式的弹窗，此时工厂模式将是你的不二之选。
例如：当我们需要调用一个非常复杂的过程时，代理模式/装饰模式/适配器模式，无意是你的首选。你将以很小的成本，提供外部调用一个复杂的过程。
每一种模式都对应着一种变化，换句话说：当我们知道了要怎样变化时，才知道要用什么模式。
（四）解决变化的问题，依靠设计模式是不够的
一般来说，在我们客户端工作中，最大的问题并不是不知道要用什么模式来应对变化，而是不知道要怎么变化。甚至，连产品经理很多时候也不知道要怎样变化。因此，一个非常恐怖的问题是：
我们并不是不知道怎么应对变化，而是不知道怎么变化。
针对这个问题，我总结的方法是：
1）不对不确定需求做设计（不做过度设计）
我给过度设计的定义是，对不确定的需求做的具有一定开发工作量的设计。过度设计有两个必要条件：
1、需求不确定
2、需要一定开发成本。
如果需求确定，有一定的开发成本，也是值得的。如果需求不确定，但是几行代码可以完成，也算不上过度设计。如果竟然需求也不确定，同时还要一定开发成本，并且还要实现，那么这部分开发就可以认定为过度设计。
2）一旦确定变化趋势，对框架动态重构，不留技术债务
框架设计是一个动态的过程，旧设计无法满足新变化，出现新变化时的开发负责人就有义务对框架做重构，以满足变化需要。
其实说到底：彻底弄清楚需求，是设计好代码的前提。
整体来说，了解设计模式，以及设计模式背后的东西，是成为一个好码农的第一步。