数据驱动编程

“数据的表现形式是编程的根本”

“更普遍的是，战略上突破常来自数据或表的重新表达――这是程序的核心所在。如果提供了程序流程图，而没有表数据，我仍然会很迷惑。而给我看表数据，往往就不再需要流程图，程序结构是非常清晰的。”

“由于缺乏空间而绞尽脑汁的编程人员，常常能通过从自己的代码中挣脱出来，回顾、分析实际情况，仔细考虑程序的数据，最终获得非常好的结果。实际上，数据的表现形式是编程的根本。”

――《The Mythical Man-Month》Frederick P. Brooks. Jr.

 

我之所以老生常谈这个问题，是因为我们的程序员反复地在这个问题上犯错。

 

每个程序员都应当记住：数据是程序的核心。代码的实现总是和数据结构紧密相关。

在设计程序之前，精心地选择一个合适的数据结构是非常重要的。因为，代码总是围绕着数据而展开。聪明的程序员一般都比较懒惰，他们双手抱头，舒适地背靠转椅，并不急于编码。而是静心思考，等待灵感的出现。找到合适的数据结构，远比匆匆编码重要。他们在适当的时机才会编码。当然，对这个时机的把握需要程序员的判断力。而判断力是在解决问题和对问题解决方案的反思中体现出来的。

 

       数据比程序逻辑更容易理解。你认为用初始化的数组来表示分支，还是用switch语句来表示分支更容易理解？早在UNIX诞生之前就已经有相当多的实践可以证明数据驱动编程的重要性。UNIX的一系列工具包都是以数据为核心的。grep,lex,yacc,sed,awk,make,ms,tbl,troff,eqn…不胜枚举。事实说明每一千行代码的BUG数量跟具体的编程语言无关。要减少BUG的密度，减少代码量是一种行之有效的办法。

 

数据驱动编程需要将代码和数据结构划分清楚。在改变程序逻辑的时候，只要改变数据结构中的数据，而不需要改变代码。数据驱动编程不同于面向对象编程。数据驱动编程中，数据不仅是对象的状态，而且还定义了程序的控制流。数据驱动编程首先关注的是编写尽可能少的代码。而面向对象编程首先关注的是封装。数据驱动编程也不是状态机编写。状态机当然也可以用表的形式来定义。

 

其实用一个简单的表或数组就可以把代码正文部分（TEXT）压缩掉好几倍。如果以后添加或删除分支，只要改变表或数组就可以了。编写一个解决N种情况的程序总比编写直接解决20种情况的程序好。

 

我不是说我们都得用数据驱动编程来代替switch语句。世上没有所谓的不二法则。关键还是看具体情况。这取决于程序员的判断能力。我也不能完全肯定我对上述代码的评价是否正确。因为我肯定没有代码的维护者熟悉这段代码。现在如此多代码有上述类似风格，肯定是有历史原因的。程序开发心理学可以很好地解释这一现象：大家都这么编写，我也就这么编写。从众心理本身无可厚非。但是在程序开发这一领域里，还是要多持一些怀疑态度的。我经常怀疑自己。我认为我从来就没有编写过完美的代码。我也希望有人能跳出来和我讨论这个问题。问题越辩越清。编程是一门艺术，艺术是需要用心去反复雕琢的。

 

总之，我要阐述的是两条重要的原则：

1、将重复性的代码改为表实现。用表来替换冗长的类似的代码。

2、用数据结构来构造代码。

这两条原则的目的是减少代码量。减少代码量的目的是减少BUG。

 

所有的程序员都应该仔细地审视代码。反省是否用正确的方法解决了正确的问题。