《大话设计模式》讨论



曾经在我一开始学习设计模式的时候（那时候我还不会C#，用的是VB），我梦想用设计模式编写那些极端通用的，可重用的软件（GoF的设计模式副标题也是这么说的），那时候我经常指着我的代码对别人说，你看，我只要在配置文件里面修改下，我的程序就可以适应不同的需求而不用修改！但是后来我突然惊讶地发现，所谓“极端通用的程序”其实就是在创造DSL。或者简单地说，就是编写一个核心，用配置文件实现装配，配置文件相当于一种领域编程语言，而我的程序核心相当于这种语言的解释器（XML API相当于词法、语法分析器）。

我为什么要费力编写一个脚本语言的解释器呢，当配置文件复杂的时候，程序的配置出现了困难——配置文件的配置方法（市面上的所谓介绍Hibernate或者Spring的书，实质上是介绍配置Hibernate、Spring等等如何编写配置文件的书）的复杂度难过了编写程序——很多小公司为什么总是发明ORM或者IoC框架就是这个道理。

所以，动态的、脚本化的、交互的语言会在这几年突然走红，比如Ruby或者Python，甚至Lisp这种上古时代的语言都重新出山。你不是说程序需要修改吗，我直接修改源代码好了——源代码就是配置文件。

说这些是什么意思呢？其实软件的开发方式在经历一场翻天覆地的变化，那就是程序设计语言已经发展到可以随心所欲地表达程序员意图的程度了。而设计模式也好、重构也好，它们的本质是为了当时软件开发的需要——在那个时候软件生产效率低下，设计和编码是分开的——似乎架构师负责那些“宏观”的设计，程序员负责将设计细化成代码。设计模式的本质是为了避免设计的改动造成代码的重写。所谓重构就是根据代码优化设计。而现在的主流已经淡化了设计和编码的界限。设计就是编码，编码就是设计。程序中没有那些为了实现设计意图而出现的硬编码，程序代码本身既是体现架构师设计意图的说明也是直接可以运行的程序。这是设计模式消亡的根本原因。

以前一个典型的项目组可能是这样的，一个“架构师”+10个程序员。现在架构师自己就能操纵整个程序，程序员呢，下岗了。当然你也可以说，现在的程序员必须懂得架构设计，否则它会在和工具改良的竞争中被淘汰。这就好比以前蒸汽火车的司机一般要3~4个人组成，两个人添煤，一个人看信号，一个人驾驶。后来换成内燃机车，变成两个人，一个人看信号，一个人驾驶。后来的电气火车实现了计算机自动控制，那个看信号的也不需要，只需要一个人驾驶了一样。

    有一点是肯定的，那就是随着工具的改进，那些平庸的、注重形式的、人海战术的、拘谨而不思进取的开发者以及企业将很难生存下去。因为一个看似井井有条按部就班的团队（创业公司们将他们称作“委员会”），内部暗藏着巨大的拒绝变革的力量。