近期思考的对程序和系统的一些优化

1、我们各个模块间的通信一般是通过消息。在发送消息的地方，我们目前一般是发送时直接构造消息。这个方法有个不好的地方就是如果一个程序中有多个地方需要构造消息，则构造消息的代码会被重复多次，而且同样的事情散步在很多的地方，难于修改维护。所以必要明显的增加一个API层，负责从数据到消息包的转换。这样要更改包的定义只要修改指定的函数即可。但是如果将字段以参数传入，则可能会遇到一种情况——函数的参数会经常改变。这是一个问题。也许更改调用点是一个很笨但很现实的方法。
2、网元代理对外要发送很多消息，都是要发送指定的网元（全局只有一个）或板卡（如何定义板卡？可以理解为一个网元的多个设备中的一个。比如，AG是一个网元，它由很多的相同的AG板卡共同来构成的）的。可以将构造这些消息的函数作为网元类的方法。
3、将系统中各个程序中通用的部分抽取出来，用动态链接库做成一个公共的模块，供各个网元调用。比如，各个网元需要和网管系统进行通信，完成网管功能。则网管系统可以对网元提供网管功能API接口供网元调用，这样可以有效的去除重复，另外也方便进行调试。
4、应用存储过程
目前的问题，数据库中的数据往往被多个网元访问，而他们访问的方式时直接组装sql语句，然后进行数据库操作。这样整个数据库的结构就完全的暴露给多个客户端。
这样导致的问题是：
1）应用程序和数据结构耦合的太过紧密，对数据库结构的更改基本是不可能的（比如如果想把USER表根据tel字段进行分表，或者更改某字段的名称）
2）效率。复杂的数据操作效率会比较低。
3）同样的东西，可能要在不同的客户端重复几遍。造成了代码的重复。
可以使用存储过程来解决这个问题。
有一个问题就是，应用程序中对数据库的操作可能非常多，而且有的又非常小，完全更改为存储过程是否会造成存储过程过于膨胀，而且丧失了原有的简单明了性。
存储程序可以提供改良后的性能，因为只有较少的信息需要在服务器和客户算之间传送。代价是增加数据库服务器系统的负荷，因为更多的工作在服务器这边完成，更少的在客户端（应用程序）那边完成上。
在数据库和应用程序间做一个抽象层还是非常有必要的。

上面这些是我在开发和维护过程中发现的问题，这些想法不一定要马上实现，因为要考虑现实的因素。但是可以在下一个版本中进行优化。