我遇到过一些使用规则引擎的案例，似乎每次都不是顺顺利利的（也许我不是一个好的样本）。规则引擎经常提到的要点是，允许财务人员自己来制定大连财务软件开发规则，所以不需要程序员的参与了。这听上去似是而非，而且实际上很少是这样的。 虽然如此，它在BusinessReadableDSL方面还是有价值的，其实这也是这种计算模型中我觉得有价值的地方。但是这里存在着很多风险，最大的风险是，当你低头关注一系列规则时，规则的交互经常变得异常复杂，特别是存在关联，例如规则的操作改变了其他有关联的规则条件的状态。

我经常听到这样的说法，大连财务软件开发案例规则很容易制定，但是很难维护，因为没有人可以理解其中隐藏的程序流。这是抛弃命令计算模型带来的问题。命令代码的问题相对容易理解它是如何工作的。而一个产生式规则系统好像更容易带来一个问题，那就是某处的一个简单的改变带来了大量无法确定的后果，所以很少会顺顺利利的。 我没有花费足够的时间在这些系统上面，只是有一些认识，我们应该遵循一些要点： （1）规则数量要少，否则会带来效率和理解上的问题； （2）我倾向于规则要少关联； （3）测试问题。

上面这些让我觉得要避免通用的规则系统。产生式规则的基本思想是很简单的。

为了更好地控制，要显得规则在一个很窄的上下文中。当然，如果你想使用规则引擎，我建议你进行验证通用的规则引擎和手工的域的特定实现，你可以比较一下，找找感觉。 5. 重构 在软件工程学中，重构（Refactoring）一词的流行源于敏捷方法拥趸的大力推广。在极限编程中，重构是有所特指的，意思是代码重构。 "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." ——Martin Fowler in Refactoring Improving The Design Of Existing Code 敏捷开发者认为，软件开发的基本顺序为：收集和整理用户故事→设计测试用例→编写代码→代码重构→形成框架和架构→持续演进。

在大连财务软件开发案例过程中，代码重构具有重大的意义。一方面，它使编写代码更加敏捷，从而快速响应用户故事；另一方面，软件开发费用和工期决定了一款软件是否开发成功，它担负着形成框架和架构的使命，从而使软件的演进更加有效。 Robert C.Martin在Agile Software Development：Principles,Patterns,and Practices一书中有一段关于重构的讨论。首先，他针对Martin Fowler的定义提出了一个问题： 可是我们为什么要改进已经能够工作的代码的结构呢？不是还有句古老的谚语：“如果它没有坏，就不要去修理它”吗？