合适的地方使用合适的技术

在合适的地方使用合适的技术，我想这一点没有人会反对。而且大多数人都会觉得做到这一点极端简单，无需乎强调。大家可能会觉得问题倒是在于怎么断定什么是合适的技术这个问题。

但其实这两个问题（1、使用合适的技术，2、判定技术是否合适）并没有明确的分界线。因为显然如果不能判定技术是否合适，我们就不能使用合适的技术。

现在说一下我判断技术是否合适的基本原则。1、要经过时间的考验。2、要有比较严密的理论基础。3、技术本身的流行度高。

看看软件开发过程中涉及到的问题。1、理解问题域。这个过程叫做什么业务建模也罢，叫做什么需求分析也罢，主要的目的就是理解问题域。2、设定解决方案。 这个区间承上启下，是一个关键环节。它一方面影响到问题的解决，一方面也反过来影响到问题的理解。因为解决方案是一个人对问题理解和知识结构做输入产生的 输出，而知识结构跟问题理解是一个扯不清的互相关联的参数。3、实际的解决问题。好多人认为，这个环节比较简单，其实不然，这个环节要把一个世界里的东西 投射到另一个世界里（从现实世界到计算机世界），这里面就会涉及到如何投射的问题，而如何投射显然依赖于：问题模型、计算机模型。大多数人会认为这两个中 前一个已经完成了，而后一个很简单，所以投射不会很复杂，可事实上绝对不是如此，原因是：我们一般并不会把问题模型直接投射到裸的（原始的）计算机模型， 而是投射到被各种装备大大增强了的计算机模型上，比如，我们不会直接处理硬盘的数据读写，而可能是考虑把数据放入数据库系统等等。显然，这个投射过程严重 依赖于我们对于目标机器的设想和假定。也依赖于我们个人占有的信息量或者叫做知识量。4、各种偶发事件的处理。这里面主要包括信息的翻译失真，投射的不匹 配导致的困难，经济压力和时间压力等等。

所以，我们一定要在合适的地方使用合适的技术，才能满足在特定性价比的情况下制造出产品——软件系统。

关于问题与和解决方案，属于特定的领域的专业知识，有其特殊性，我大体上不涉及，我只关注实际的解决问题这个环节。我们知道，工作主要来源于投射，而投射的工作量依赖于问题域和解空间的差异性的大小。差异越小，同质化越强，投射越简单，反之亦反。

这就要求我们引出一个概念叫做DSL。这个概念的引入主要是想弥补我们的翻译（投射）的巨大鸿沟，通过一个或者多个中间翻译站，我们可以比较自然和直观的在人脑复杂度承受范围之内解决复杂问题。

到现在为止，我们都在说形而上的理论，现在我们从形而下的实践开始，两头逼近，搞出个结论。

对于任何软件系统，都会牵扯到：输入输出、处理、状态（或数据）存储（或者叫做永久化）。处理各不相同，可重用的一些方面也已经被总结出来了，比如：事 务，身份认证和安全，冗余备份和分布，处理过程（或者运行轨迹）的记录等等，这些是处理中可以重用的部分，总体来说，处理可以重用的比输入输出和状态存储 少的多。

对于输入输出，根据其对象不同，可以分为：跟人类的交互，跟机器（网络节点、别的进程等等）的交互两大类。根据其内容的不同，可以分为实体信息的交互和控 制信息的交互。我们对于实体信息，总结的和可重用的东西比较多，比如：实体信息包括数字、字符（串）、图形图像、声音、视频以及混合信息，它们的传输、存 储、解析翻译（Codec）和获取生成都是可以重用的部件。而对于控制信息，其定义就有点杂乱，投射到人类交互这个层面，会有好多称作Control的可 重用部件用来表达人和软件系统交换的控制信息，投射到机器交互这个层面，显然就是我们不同的【网络】通信协议了，它们主要是维持和管理控制实体信息交互而 采用的，一般称作信令。

对于状态存储，现在比较自然和流行的包括三类，二进制内存存储， 二进制或者文本的【xml】文件存储，二进制的数据库存储。其实（文本可以认为是一种特化的二进制）。对于这些实体信息或者叫做状态，它们的操纵和处理可重用的地方非常大。

上面简要分析了最低层次的（相对而言）的Domain，对于这些Domain，我们有没有对应的DSL呢？

有的，显然，数据领域是SQL、XQuery，处理领域有无数种计算机编程语言，它们都比较合格，尤其是提供了OO能力和Aspect能力以后，用来描述 处理一般没有什么困难，而表现领域（输入输出领域）呢？我认为还是有的，比如：适合图形表现的SVG，适合控制表现的XForms，适合多种实体信息表现 的XHTML2（注意其中的object），适合视频表现的Flash，这些都是该领域的特定语言，可以非常自然高效的表达希望表达的信息。

从这个低层次的分析我们就发现，我们现在把问题空间投射到解空间的方法并不是最好，甚至可以说是相当的差，而近来有些公司已经意识到这一点，比如 Microsoft，Adobe，Sun，它们分别推出了XAML，MXML，JavaFX，用来为输入输出层提高生产率。问题不在于它们的技术，而在 于：1、它们都期望绑定程序员，2、它们的技术都有一定的壁垒，3、现在它们还都不够流行。所以，我个人认为如果提供一个基于标准（XHTML、 XForms、SVG+Other）的表现层运行时，会有很大的竞争力。当然，我的市场敏感度极低，大家自己分辨吧。

有些程序员总是固守着自己的那一块小地盘，期待着所有的事情都用一个办法搞定，这不是不行，只是不够好而已。采用多种DSL构造Application， 一个潜在的问题是这些不同的DSL定义的部件组装在一起的问题。ORM部分的解决了数据领域和业务领域的组装问题，而新出现的表现层Runtime期待着 解决业务领域和输入输出领域的组装。

软件开发的前途看来还是比较光明的。