设计的三个境界:见山三部曲

青山禅师在回顾自己的参禅经历的时候这样说：“三十年前未参禅时，见山是山，见水是水。及至后来，亲见知识，有个入处。见山不是山，见水不是水。而今得个休歇处，依前见山只是山，见水只是水……”

这段话是典型的中国式的智慧，只可意会不可言传。参禅如此，设计不也是如此嘛。对禅学我是非常不通，要我解说更是容易招来大师的指责。不过既然和设计相通，我却想借用见山三部曲来衡量设计的境界。

王国维在《人间词话》说：古今之成大事业、大学问者，必经过三种之境界：

1. 昨夜西风凋碧树。独上高楼，望尽天涯路
2. 衣带渐宽终不悔，为伊消得人憔悴
3. 众里寻他千百度过，蓦然回首，那人却在，灯火阑珊处

这三个境界也同样适合我们软件工作者。可是也正是因为有前人那么精辟的话在，我来贸然解释，非常惶恐。如有偏差，望大家多多批评。

见山是山，见水是水

这个时候，我们对设计都是一些简单想法。从直接编程到先设计后编程，我们往往非常惶恐。我第一次设计的时候，真的不知道从何入手。和同事小祝两人的直观想法就是画静态类图。那时对我们来讲，将数据结构转换成类结构，就是设计了。幸好，后来公司也意识到这个情况，派了高手过来，带着我们过河。

不过由于那次是我们公司第一次大规模设计，所以很多东西也不是很明白。对于很多业务，也不是我们设计者非常理解的。所以设计的很多时候，都是在询问其业务意义。再加上一些简单设计模式的理解。再加上我们那个奋力拼搏非典的春天。第一个设计就是这样完成的。

可以想象，这个设计中存在的问题并不在于它不能解决问题。说得不好听，没有设计，我们照样可以做软件。我们只是比之前的盲目状态稍微好点。但只是意识到了，思想还没有跟上。这时候，面对的问题，都是就着问题解决问题。大部分都停留在表层。这个系统基本就是简单再现了原有系统的框架结构。

此种情况下，山在架构师眼中，就是山上的地貌。而设计出来的系统，也就像工笔画一样。

见山不是山，见水不是水

人们在学习软件设计的过程中，抽象是最容易被提及的技术和方法。包括类的抽象、系统的抽象、框架的抽象。对于类的抽象我们一般比较擅长。可是真正在业务上的抽象并不是那么容易的。

这个时候，很多设计者容易躲避繁杂的业务，而去从核心上抽象整个系统。我也有这样的经历。设计的时候，将系统看成一个简单的模型，比如：业务流模型，MVC模型等等。从这个模型入手，再解决几个系统的重要问题。剩下的很多业务问题，都交给程序员完成。

据说这个模式，现在还比较流行。我想这也许是因为很多设计者在这方面比较相像。将系统的设计分成两部分：第一、系统架构，也就是前面说的。第二、模块设计，也就是交给程序员或者组长继续设计模块。华为的研发模式好像就是这样的。我对这个模式没什么意见，毕竟，适合人的模式，才是有效的模式。

在这个设计中，系统往往已经不再是业务系统，而变成一个抽象的系统。业务都是抽象系统上的枝叶。

见山只是山，见水只是水

此山已经非彼山了。当系统架构师将业务概念融会贯通的时候，虽然存在抽象模型，但是系统的重点仍然是业务本身。这样的系统才是业务系统。这样的系统才是完整的，这样的系统才是系统的。

我在这方面只能说有朦胧感觉，不敢说自己有什么心得。

要用业务的概念来描述整个系统，那么系统看上去还是业务的。在架构师眼里，系统是一个完整的系统，他们不会只关系核心而忽略更为重要的业务，这样更容易真正从系统的角度来思考整个业务系统。

山，在他们眼里，是系统的山。他们能发现其中的地势，哪里攀爬困难，哪里适合建房。也能理解内部的地质结构，哪里是实心的，哪里存在溶洞。哪里有地下泉水。还知道哪里容易发生泥石流之类的地质危害。

面对业务系统，我们不是也该如此吗？抽象的框架是为了更好地理解系统，但是理解业务中真正的变化部分才是设计的重中之重。要不我们为什么一直在高呼“可维护性和可扩展性”呢？正是因为难以做到，才更证明这是一个比较高的境界。

_____________________________

很多时候，境界的理解，是因为个人的环境以及个人的修养。一些浅显的见解，只是在这方面做一些尝试。希望对大家能有些许的帮助。