文章地址是：http://dev.csdn.net/author/absurd/135d9e207d024cf79c9bc8f50f45ce5c.html
他的文章举了个例子：
前几天遇到一个问题，要定义一组宏，它的格式是这样的：
KEYMAP(GDK_Op_Left, GDK_F12, DIKS_F12)
KEYMAP(GDK_Op_Right, GDK_F13, DIKS_F13)
…
大约有30多行，第一列的Op_Left之类是自定义的按键，是我们讨论的结果，放在一个表格中，手工把这份表格转换成以上的宏，不难也要不了多少时间，但这样单调的事很容易出错，特别对于我这样粗心大意的人来说。于是决定用awk来做：
awk 'BEGIN{i = 4} {print "KEYMAP(GDK_" $1 ", GDK_F" i ", DIKS_F" i ")"; i++}' keys.txt
这就是代码产生器！就一行代码。简单吧，它却产生了30多行代码。其实我经常在用这样的代码产生器，给我节省了不少时间，减少了出错的可能。所以能用脚本就用脚本，脚本实现困难时才考虑用C/C++等编译语言。
我告诉文章的作者，他这样生成代码的效率是很低的，你每次生成代码都要
修改代码生成器以生成你想要的代码。如果是我，我会定义好一套模板，
定义好一套标准的文档和约定，然后根据文档、约定、模板来生成代码，
代码生成器不用修改，只需要修改文档和模板就行了。
最重要的是，文档可以根据UML里的序列图来生成，并根据活动图、泳道图等来
组织生成的代码文件。当然，也可以根据流程图来生成。
根据分析设计图生成规范的文档，再定义好模板就可以生成代码了，
这也许就是未来软件工程自动化要走的路：
分析设计(流程图、UML图、伪代码、广义文档) → 生成规范文档 → 建立模板 → 生成代码
以那个生成宏的例子来讲解如何实现软件工程自动化：
第一步：分析设计
这个例子很简单，就是一个宏的表格，
可以理解为一个数据库的表，有字段名，有数据，
或者用word画的一个表格，或者其它什么的
第二步：生成规范化的文档
这里生成一个表格：
按键映射表
自定义键
键一
键二
GDK_Op_Left
GDK_F12
DIKS_F12
GDK_Op_Right
GDK_F13
DIKS_F13
第三步：建立模板：
[循环：表名=按键映射表] KEYMAP([自定义键],[键1],[键2])
第四步：生成代码
这一步应该由代码生成器来工作，不过也需要人参与，
比如生成后还要做些细微的调整。
需要说明的是,第一步和第二步似乎都是表格,那第二步根本都没必要,
直接根据第一步的表格 来生成不就行了,
为什么要有第二步,这第二步至关重要，虽然都是表格,但第一步的表格并不是规范的表格,
也许第一步的表格是Excel表格,或者Word表格,或者Visio表格,或者干脆就是画图工具画个表格,
而第二步的表格是规范化的表格,第二步的表格只有一种格式, 至于具体是什么公式,
这也是未来软件自动化需要解决的事情,就是需要定义一种标准的文档, Visio\Rose等都能生成
这种标准的文档. 有了这种标准化的文档, 之后的自动化工作才好开展, 否则,一切都是空谈.
这种标准化的文档是软件自动化的基础, 只有先打好这个基础, 之后的所有自动化才有了依托.
对于上面的模板，比如循环，有些循环更复杂，需要有筛选过滤与组织，
比如我做过一个模板，用来验证字段有效性，比如验证用户输入是否为空：
<循环：表名=学生信息表; isnull=false>
if(eStudent.<字段名>==""){
return "请输入<字段标题>!");
}
</循环>
上面可以换一种写法：
<循环：表名=学生信息表 id="学生信息1">
<选择 [学生信息1.isnull]=false>
if(eStudent.<学生信息1.字段名>==""){
return "请输入<学生信息1.字段标题>!");
}
</选择>
</循环>
上面的代码很类似于伪代码，但是和伪代码有本质的区别是，这个能直接生成可运行的程序代码，
所以比伪代码多很多内容，更为细致。
对于如何定义文档，如何定义模板，需要制定一套标准，并预设好大量的资源，
这些资源必须是开放式的资源，现在有很多成熟的框架是封闭的，是要收钱的，
无法满足自定义流程等。很多公司有一些这方面的经验，却都据为己有，
不愿意与别人分享，而要实现软件自动化，必须有大量的知名软件公司的参与才能实现的。
然而实现起来往往是渐进的，而且他们也没有找到一种可行的方法来实现软件自动化，
虽然在某些特殊场合可以生成，却不具有普遍性，无法推广到一般性场合。
所以代码生成器给人的印象就是只能做简单的工作。实际，软件自动化是可以实用于所有场合的，
当然是否能用还得需要考虑成本、版权等等缘故。既然提供这样一种自动化的方案，用不用是个人
愿意而已。
对于能预知未来软件自动化的出路，现在看来却是可悲的。就象垃圾自动回收机制，
上世纪六十年代就已经有这种技术了，但却受内存的限制无法推广，直到最近几年，
内存非常便宜才大量推广，即使如此，.NET的垃圾自动回收机制还是无法普及，对于低
配置的机子运行依旧是很慢。某个大师说要给发明垃圾自动回收的人颁发诺贝尔奖，
可那六十年代最先有这种技术时，是没人会想给他颁发诺贝尔奖的。
软件自动化现在一样缺少这种普及的环境，虽然在某些地方，某些角落里有应用，却无法普及开来。
也不仅仅是环境的问题，还有技术以及思路的问题，现在的自动化走偏了，弄了大量的框架，而这些
框架却今日用明日就被淘汰，总是新的框架取代旧的，没有消停，结果程序员与公司奔走于各种框架
之间，无所适从。而且框架，就是框框，框起来，大有违背开放的原则，最好的框架就是没有框架，
思路至关重要，方向不对，会越走越偏。越偏越远。
而Rose\Visio等设计也无法生成实际的流程代码,因为设计图缺少更多细致的数据,
即使程序员手工编写,也还需要提供大量其它的文档,比如Word文档说明，以及客户需求资料(Excel文档\Word文档) 才能工作.
Rose\Visio连手工编写都不能满足所有资料,更不用说自动化了,
这也是设计工具的局限,是局限,也是分工,Rose\Visio实现不了的,也许Word和Excel等就能做的很好,
而且Rose\Visio毕竟是一个封闭的工具，比如你想增加一些属性上去,根本增加不了,
最简单的,比如我想做一个显示学生列表的界面, 数据库里学生表有五个字段:学号,姓名,班级,班主任,备注
设计文档要求学生列表页面只显示姓名，班级,班主任, 不显示备注, 所以字段属性需要额外增加一个是否显示属性上去, Visio不可能让你增加这个属性, 所以只好将字段信息导出到Word, 然后自己在Word表格里增加这个是否显示属性, 然后就交给程序员去做.
所以,软件自动化必须是很多工具，很多公司合作才能实现的，就象汽车工厂一样,
必须各种提供零配件的公司,提供原料的公司,配送公司等等一起合作才能实现自动化,
光靠其中某一家是没办法实现规模化自动生产的.
“生成规范文档”这一步，这个文档采用什么格式也是很重要的，也许，XML是一种比较好的格式，
因为XML已经成为一种标准，功能也比较全面，但XML可读性方面比较差，根本不能跟流程图、UML图、WORD文档、Excel文档相比，除非有一种好的显示工具，比如通过XSL来格式化显示，但一样有很多问题，或者结合其它文档的易读性，综合XML的优点与其它类型文档的优点。
人们都是很懒的，即使指引出方向，也没人愿意去搞，或者关起门来搞，想拒为己有，当然，开发这些东西需要付出很大的代价，获取回报也理所当然，但是，这也会方妨碍技术的发展，技术标准是需要公开的，但工具可以各自经营。
最新评论