用C开发程序比较多的人，对函数肯定是又爱又恨：作为过程语言，函数提高了程序的调理性，利于重用维护；编程中函数的参数又让人有些恶心，如果参数很多， 要写很长的参数列表，改动起来还得时刻准备加长，（如一个验证函数，一开始只有两个参数姓名、密码，后来又要扩充上权限），C语言中的函数声明又不和定义 部分在一起，实在麻烦。参数少的时候，还可以忍受，多的时候（如将接收前台数据传到子函数中）就难以忍受。所以有些时候会写一个超级长的函数来避免向子函 数传递参数。然而这样写出来的代码可维护性极其差（试问有几个程序员对几千行代码的长函数不头痛）。
实际上解决办法是有的，并且很普通，只是要增加额外代码。用中间件Tuxedo的fml(32)方式进行过开发的都知道，Tuxedo维护了一个大的缓冲 区，程序员可以通过变量ID去取得、更改其中的值。从前台传到后台的是一个指针（缓冲区），在大部分后台函数中只需传递指向缓冲区的指针这一个参数。进而 推展开，如果把这个缓冲区声明成全局的，并且加上一定的封装，最终程序员不需要在看到可爱又可恨的指针是多幸福的事情。诚然，这样会产生一些其它问题（后 边描述），但是程序的结构性，可读行大大提高了。如果可能，前后台都采用这种方式，数据透明的传输，一般的开发人员不用再关心什么中间件、指针之类的东 西，只要知道名字（如“操作员姓名”）就可以找到、更改对应的值。前台程序中不必再写从这个form上某个edit控件取出值，转换为后台需要的形式，组 织后台程序需要的信息流；后台程序中不必把指针指来指去该是多么幸福的事情。
just one name.
对，只要一个名字。如果信息流的格式发生改变，如由fml改为xml只需要改动格式生成规则，快捷方便。这里是以tuxedo为例子，实际上如果提供一个 平台完成这些，根本不需要考虑具体的实现形式（牛人可以自己写一个类似的缓冲区管理库），还有其它一些好处，不再一一列举。
当然会存在一些问题：
1. 命名混乱。不同模块、函数中变量命名一定要控制住，否则会产生与过多使用全局变量同样的问题，不是变量找不到，就是变量乱使用，总而言之，变量混乱。
2. 缺少访问控制。数据总线相当于全局变量，任意的函数都能访问到其中的变量，如果无意中更改了，会产生莫名其妙的错误。
3. 效率会降低。当前的硬件可以忍受这些损耗。
初步的解决设想：
增加访问控制，数据总线分为程序级和交易级，程序级在本进程中始终不释放，交易级总线只在一个小的交易模块中作用。如果可能，在函数访问前可以lock一些变量，减少损失。
相关问题参见blog中其它文章
