软件开发作为一种工程技术，它所研究的一个重点就是如何才能有效降低软件产品的研发成本。在这一方向上，组件技术取得了空前的成功。它所提供的基本图景是像搭积木一样从无到有的组装出最终的产品。在某种意义上，这是对现代建筑工业的模仿和致敬。新材料，预制件，框架结构，这些建筑学的进展在软件领域被一一复制，建筑工地上的民工自然也成为了程序员们学习的楷模。毕竟，在组件的世界中码代码，基本上也是一种“搬砖”的行为。
值得庆幸的是，软件开发作为一种智力活动，它天生具有一种“去民工化”的倾向。信息产品有着与物质世界产品完全不同的抽象本质。在物理空间中，建造100栋房屋，必须付出100倍的努力，老老实实的干上100遍。而在概念空间中建造100栋房屋，我们却可以说其他房屋与第一栋一模一样，加点平移旋转变换即可。一块砖填了地基就不能用来盖屋顶，而一段写好的代码却可以在任何可用的场合无损耗的被使用。一栋建好的房屋发现水管漏水要大动干戈，而在完成的软件中补个局部bug却是小菜一碟。在抽象的世界中有效的进行生产，所依赖的不应该是大干,苦干的堆砌，而应该是发现某种可用于推导的原理，基于这些原理，输入信息可以立刻转换为最终的结果，而不需要一个逐步构造的过程。即我们有可能超越组装性生产，实现某种类似于数学的原理性生产。http://canonical.iteye.com/blog/325051
代码复用是目前软件业中鼓吹降低生产成本的主要口号之一。但是在组件技术的指向下，一般所复用的只是用于构建的砖块，而并不是某种构造原理。即使在所有信息已经确定的情况下，我们仍然不可能从需求立刻得到可执行的产品。很多代码即使我们在想象中已经历历在目，却仍然需要一行行把它们誊写下来。当我们发现系统中已经没有任何组件值得抽象的时候，仍然留下来众多的工作需要机械化的执行。代码复用的理想国距离我们仍然非常的遥远。
子例程(subroutine)是最早的代码重用机制。这就像是将昨天已经完成的工作录制下来，在需要的时候重新播放。函数(function)相对于子例程更加强大。很多代码看起来并不一样，但是如果把其中的差异部分看作是变量，那么它们的结构就可以统一了。再加上一些判断和循环，很多面目迥异的东西其实是存在着大量共享信息的。面向对象技术是一次飞跃性的发展。众多相关信息被打包到一个名称（类型）中，复用的粒度和复杂度都大大提升。派生类从基类继承，可以通过重载实现对原有代码的细致调整。不过，这种方式仍然无法满足日益增长的复用需求。很多时候，一个名称并不足以标定我们最终需要的代码结构，在实际使用的时候还需要补充更多的信息。类型参数化，即泛型技术，从事后的角度看其实是一种明显的解决方案。根据参数动态的生成基类自然可以吸纳更多的变化。经历了所谓Modern C++的发展之后，我们现在已经非常明确，泛型并非仅仅能够实现类型共变，而是可以从类型参数中引入更丰富的结构信息，它的本质是一种代码生成的过程。http://canonical.iteye.com/blog/57244 认清了这一点，它的扩展就非常明显了
BaseClass--> CodeGenerator
DSL（或者某种模型对象）相对于普通的类型(Class)，信息密度要大很多，它可以提供更丰富也更完整的输入信息。而CodeGenerator也不必拘泥于基础语言本身提供的各种编译机制，而是可以灵活应用各种文本生成技术。http://canonical.iteye.com/blog/309395 CodeGenerator在这里所提供的正是根据输入模型推导出完整实现代码的构造原理。
现在很多人热衷于开发自己的简易代码生成工具，这些工具也许可以在简单的情形下减轻一些体力工作，但是生成的代码一般不能直接满足需求，仍然需要手工执行大量的删改工作。当代码生成之后，它成为一种固化的物质产品，不再能够随着代码生成工具的改进而同步改进，在长期的系统演化过程中，这些工具并不一定能够减少累积的工作量。
修正过程 ==> CodeGenerator
为了改进以上代码生产过程，一些人试图在CodeGenerator中引入越来越多的可配置性，将各种变化的可能内置在构造原理中。显然这会造成CodeGenerator的不正常的肿胀。当更多的偶然性被包含在原理中的时候，必然会破坏原理的简单性和普适性。
输入信息 + 一段用于推导的原理 + 修正补充 = 真实模型
必须存在[修正补充]这一项才能维持以上方程的持久平衡。
为了摆脱人工修正过程，将模型调整纳入到概念世界中，我们需要超越继承机制的，更加强大的，新的技术手段。其实在当前的技术背景下，这一技术已经是呼之欲出了。这就是AOP, Aspect Oriented Programming。http://canonical.iteye.com/blog/34941
Biz ==[AOP extends]==> CodeGenerator
继承仅仅能够实现同名方法之间的简单覆盖，而AOP所代表的技术原理却是在代码结构空间中进行任意复杂的删改操作,它潜在的能力等价于人工调整。
为了实现上述生产模式，需要对编程语言，组件模型，框架设计等方面进行一系列改造。目前通用的AOP实现和元编程技术其实并不足以支持以上模式。http://canonical.iteye.com/blog/275015
这一生产模式将会如何演化，也是一个有趣的问题。按照级列理论，我们立刻可以得到如下发展方向：
Context0 + DSL1 + EXT0 = DSL0 Context1 + DSL2 + EXT1 = DSL1 ...
http://canonical.iteye.com/blog/33824
Witrix平台中BizFlow可以看作是对DaoWebAction的修正模型，但是它本身具有完整的意义，可以直观的被理解。在BizFlow的基础上可以逐步建立SeqFlow，StateFlow等模型。http://canonical.iteye.com/blog/126467
现在有些人试图深挖函数式语言，利用模式匹配之类的概念，做符号空间的全局优化。但是我们需要认识到通用的机制是很少的，能够在通用语言背景下被明确提出的问题更是很少的。只有在特定领域中，在掌握更多局部信息的情况下，我们才能提出丰富的问题，并作出一定背景下的解答。DSL的世界中待做的和可做的工作很多。http://canonical.iteye.com/blog/147065
对于程序员而言，未来将变得越来越丰富而复杂，它将持续拷问我们的洞察力。我们不是一行行的编写代码，把需求一条条的翻译到某种实现上，而是不断发明局部的生产原理，依靠自己制定的规则在抽象的空间中不断的创造新的表象。