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

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

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

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

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

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

见山是山,见水是水

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

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

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

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

见山不是山,见水不是水

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

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

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

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

见山只是山,见水只是水

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

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

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

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

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

_____________________________

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

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值