四
四库全书
Unregistered / Unconfirmed
GUEST, unregistred user!
为MIS 系统喊冤
jinles jinles@371.net
摘自PTM评论第9期
--------------------------------------------------------------------------------
在我所接触过的程序员当中，至少有百分之九十的人对MIS 系统不感兴趣。如果他的工
作恰好是MIS，那是为了生活不得已而为之。我以前也是抱着同样的态度看“程序世界”的。
大家都比较喜欢编个操作系统，或者与系统底层有关的东西，觉得那样有成就感，能够展
示出自己的实力；而编MIS 相对来说容易实现，重复性工作较多。
去年十月份，我来到现在的公司，接手一位同事的程序。那人感兴趣的是底层，而不
是MIS。当然他的编程水平是不容置疑的，因为他已经独立编出过比较成熟的软件。但我接
到程序时大吃一惊：几乎没有注释，不讲究缩进规则，程序名、过程名随意选取（英汉均
有），除了程序源代码之外文档一无所有。我对程序的流程及特性在两个月之后才完全明白，
而其实并不复杂。最可笑的是，我在原来的基础上修改时，客户有时竟比我更了解程序。
目前又接手另一位同事的程序。程序基本能用，但程序的“复杂性”太大了-- 一个过
程一般都有一百多行代码，同样几乎没有注释，仅有的“注释”是无用的代码，更让人啼
笑皆非的是他宁愿复制十次同样的代码，也不愿把它改成一个过程调用。总之，他给我的
感觉是不懂软件工程，甚至可以说不懂编程的基本常识。
另外，在我刚来公司的时候，前面提到的第一位同事是我们的小组长，给我们分配工
作时只是说一下你要做哪一块-- 仅此而已。印象最深的一次是，客户要求为一个特定的部
门编一个程序，并提供了一张表格。我对组长说只有表格不足以掌握他们的确切需求，他
对我说这就是用户的最初需求。我当时就愣住了，难道用户的需求由自己想象？
以上的情形，想必做过MIS 系统的人都有所体验。不知大家有没有想过为什么他们会喜
欢编写底层，或者汇编级的程序，而不愿编写MIS 程序。我觉得，那时因为他们不能胜任
MIS 的开发。他们所喜欢的底层程序，是一个独立的程序，数据流可以记在脑子里，过程名
可以记在脑子里，就那么几个处理，反复反复几次就编出来了。如果让这个程序扩大一点，
或者让这个程序稍有改动，也就只有他们自己需要知道程序怎么改，说不定往往就是索性
重新调整全部流程-- 反正全部流程也不复杂。如果把MIS 系统比作马拉松，那“底层”程
序就是百米赛跑，即使跑得很慢，也不过比别人慢两、三秒！这些是我个人对喜欢底层程
序的根源的分析，无意影射某一个人，言语过激之处请大家谅解。
下面我谈一下我对软件工程的理解。
在设计MIS 的一个模块时，我弄清用户需求（通过阅读源程序//??），确切地说是弄清了程
序要实现的功能。对于一个小型的MIS 来说，其需求是容易掌握的。然而，我个人认为要想
通过与用户的交流绝对清楚的掌握用户需求是不现实的。在程序初期，只要掌握用户最主
要的需求就可以了，其他的可以通过其他方式获取，如同类产品、报纸、相关书籍。在主
要需求的基础上开始设计，由设计去发现和进一步挖掘用户的需求。这是一个螺旋式上升
的过程。
设计开始时，首先设计数据库，然后设计数据库上的各种操作，模拟程序运行。比如
要编一个图书管理系统，在建成整个库结构之后，我开始模拟程序运行：新书入库，书籍
查询等等。这个库所能实现的全部操作都在这个阶段，并把实现记录下来。建库时需要注
意一定的规则，每一个模块确定一个前缀，此模块下所用的所有表、存储过程、查询，都
要加上这个前缀。每一个表也要遵守一定的规则：一个完整的单词；两个单词的组合，第
一个单词只保留至多三个字母，第二个单词为全部；多个单词的组合，只保留一个关键词，
其余的用其首字母代替。在建表时要遵守字段命名的规则：相同或相似的字段，要用同一
个名，同一种类型，不允许乱用字段名。为此，我专门编了一个小程序管理字段名。每次
使用时，可以先查询是否有该字段名的定义，如果没有就定义，如果有就按原来的定义。字
段名的取名规则也和表名的取名规则一样。
设计完数据库后，再开始进行程序框架设计。此时的设计就简单得多了，因为数据库
上能够实现的功能基本上代表了整个程序的功能。只要注意一下程序间模块的调用关系即
可。目前我正在数据设计阶段，所以对程序设计不敢多加评论。
在我设计整个数据库的框架的时候，总感觉不容易入手：若设计得简单，担心将来程
序不够实用；若设计得复杂，又担心考虑不足，程序会存在隐患。这些担心都在着手设计
时不攻自破。建过表之后，实现操作时，很容易看到程序可以实现的功能，以及程序要扩
展时的复杂性。其他方面的担心也都是在实现之后解决的。
在设计时，我一直反复阅读软件工程书，当我最终放下书本时，我发现我已经掌握软
件工程的思想了。只有MIS，才会提供这样绝好的机会。我不希望自已在别人利用工具自动
生成代码时还在为自己编写的微不足道的小程序而沾沾自喜-- 无论它多么完善！
对于软件工程工程而言，只学游泳理论而不下水是没有用的。
-------------------------------------------------
四库评论：
这是一篇很有现实意义的文章，的确在很多人心目中，MIS根本就没有技术含量，只不过是
对数据库的操作而已，所以很多人根本看不起MIS软件，例如 用友，金蝶，速达，的东西被说的
一无是处，而且，自己也不愿意写MIS软件，甚至有人以不写MIS为豪。
但是，现在是一个“大系统”的时代，很少有靠单枪匹马就能写出来的系统了，系统越来越
复杂，人员配备也越来越多样化，那么，MIS到底有没有技术含量呢？文中指出，只有MIS才为我
们提供了实现软件工程的最好机会，就我的经验来讲，想想也是如此，对于MIS来说，数据库设
计是最为关键的，一个好的数据库设计不但能够简化编程，而且能够提供很好的系统扩展能力，
一个规范的编码规则可以成倍的节约后期修改和维护成本。而且，MIS系统多是系统分析员，程
序员，领域专家，文档人员，测试人员共同劳动的成果，如果说程序员没有会计基础，他就很难
搞明白“加权平均法”和“移动加权平均法”的区别，MIS系统是需要很多的行业知识的，试想
，没有财务领域的专家，只靠程序员，能够做出“管家婆”这样的软件吗？可能有的程序员看到
管家婆的界面，会说，这个我也能做，但是，界面后暗流涌动的数据流向，数据处理方法大家能
清楚吗？陆游说的“汝辈学作诗，功夫在诗外”应该就是就是这个道理。
所以说，我们做MIS的不必以此为自卑，我们可以自豪的说，MIS不但在软件工程方面有技术
含量，并且，我们通过作MIS能够成为领域专家。
众所周知，Delphi最拿手的就是作MIS，各位dfw对此有何看法，请畅言。
jinles jinles@371.net
摘自PTM评论第9期
--------------------------------------------------------------------------------
在我所接触过的程序员当中，至少有百分之九十的人对MIS 系统不感兴趣。如果他的工
作恰好是MIS，那是为了生活不得已而为之。我以前也是抱着同样的态度看“程序世界”的。
大家都比较喜欢编个操作系统，或者与系统底层有关的东西，觉得那样有成就感，能够展
示出自己的实力；而编MIS 相对来说容易实现，重复性工作较多。
去年十月份，我来到现在的公司，接手一位同事的程序。那人感兴趣的是底层，而不
是MIS。当然他的编程水平是不容置疑的，因为他已经独立编出过比较成熟的软件。但我接
到程序时大吃一惊：几乎没有注释，不讲究缩进规则，程序名、过程名随意选取（英汉均
有），除了程序源代码之外文档一无所有。我对程序的流程及特性在两个月之后才完全明白，
而其实并不复杂。最可笑的是，我在原来的基础上修改时，客户有时竟比我更了解程序。
目前又接手另一位同事的程序。程序基本能用，但程序的“复杂性”太大了-- 一个过
程一般都有一百多行代码，同样几乎没有注释，仅有的“注释”是无用的代码，更让人啼
笑皆非的是他宁愿复制十次同样的代码，也不愿把它改成一个过程调用。总之，他给我的
感觉是不懂软件工程，甚至可以说不懂编程的基本常识。
另外，在我刚来公司的时候，前面提到的第一位同事是我们的小组长，给我们分配工
作时只是说一下你要做哪一块-- 仅此而已。印象最深的一次是，客户要求为一个特定的部
门编一个程序，并提供了一张表格。我对组长说只有表格不足以掌握他们的确切需求，他
对我说这就是用户的最初需求。我当时就愣住了，难道用户的需求由自己想象？
以上的情形，想必做过MIS 系统的人都有所体验。不知大家有没有想过为什么他们会喜
欢编写底层，或者汇编级的程序，而不愿编写MIS 程序。我觉得，那时因为他们不能胜任
MIS 的开发。他们所喜欢的底层程序，是一个独立的程序，数据流可以记在脑子里，过程名
可以记在脑子里，就那么几个处理，反复反复几次就编出来了。如果让这个程序扩大一点，
或者让这个程序稍有改动，也就只有他们自己需要知道程序怎么改，说不定往往就是索性
重新调整全部流程-- 反正全部流程也不复杂。如果把MIS 系统比作马拉松，那“底层”程
序就是百米赛跑，即使跑得很慢，也不过比别人慢两、三秒！这些是我个人对喜欢底层程
序的根源的分析，无意影射某一个人，言语过激之处请大家谅解。
下面我谈一下我对软件工程的理解。
在设计MIS 的一个模块时，我弄清用户需求（通过阅读源程序//??），确切地说是弄清了程
序要实现的功能。对于一个小型的MIS 来说，其需求是容易掌握的。然而，我个人认为要想
通过与用户的交流绝对清楚的掌握用户需求是不现实的。在程序初期，只要掌握用户最主
要的需求就可以了，其他的可以通过其他方式获取，如同类产品、报纸、相关书籍。在主
要需求的基础上开始设计，由设计去发现和进一步挖掘用户的需求。这是一个螺旋式上升
的过程。
设计开始时，首先设计数据库，然后设计数据库上的各种操作，模拟程序运行。比如
要编一个图书管理系统，在建成整个库结构之后，我开始模拟程序运行：新书入库，书籍
查询等等。这个库所能实现的全部操作都在这个阶段，并把实现记录下来。建库时需要注
意一定的规则，每一个模块确定一个前缀，此模块下所用的所有表、存储过程、查询，都
要加上这个前缀。每一个表也要遵守一定的规则：一个完整的单词；两个单词的组合，第
一个单词只保留至多三个字母，第二个单词为全部；多个单词的组合，只保留一个关键词，
其余的用其首字母代替。在建表时要遵守字段命名的规则：相同或相似的字段，要用同一
个名，同一种类型，不允许乱用字段名。为此，我专门编了一个小程序管理字段名。每次
使用时，可以先查询是否有该字段名的定义，如果没有就定义，如果有就按原来的定义。字
段名的取名规则也和表名的取名规则一样。
设计完数据库后，再开始进行程序框架设计。此时的设计就简单得多了，因为数据库
上能够实现的功能基本上代表了整个程序的功能。只要注意一下程序间模块的调用关系即
可。目前我正在数据设计阶段，所以对程序设计不敢多加评论。
在我设计整个数据库的框架的时候，总感觉不容易入手：若设计得简单，担心将来程
序不够实用；若设计得复杂，又担心考虑不足，程序会存在隐患。这些担心都在着手设计
时不攻自破。建过表之后，实现操作时，很容易看到程序可以实现的功能，以及程序要扩
展时的复杂性。其他方面的担心也都是在实现之后解决的。
在设计时，我一直反复阅读软件工程书，当我最终放下书本时，我发现我已经掌握软
件工程的思想了。只有MIS，才会提供这样绝好的机会。我不希望自已在别人利用工具自动
生成代码时还在为自己编写的微不足道的小程序而沾沾自喜-- 无论它多么完善！
对于软件工程工程而言，只学游泳理论而不下水是没有用的。
-------------------------------------------------
四库评论：
这是一篇很有现实意义的文章，的确在很多人心目中，MIS根本就没有技术含量，只不过是
对数据库的操作而已，所以很多人根本看不起MIS软件，例如 用友，金蝶，速达，的东西被说的
一无是处，而且，自己也不愿意写MIS软件，甚至有人以不写MIS为豪。
但是，现在是一个“大系统”的时代，很少有靠单枪匹马就能写出来的系统了，系统越来越
复杂，人员配备也越来越多样化，那么，MIS到底有没有技术含量呢？文中指出，只有MIS才为我
们提供了实现软件工程的最好机会，就我的经验来讲，想想也是如此，对于MIS来说，数据库设
计是最为关键的，一个好的数据库设计不但能够简化编程，而且能够提供很好的系统扩展能力，
一个规范的编码规则可以成倍的节约后期修改和维护成本。而且，MIS系统多是系统分析员，程
序员，领域专家，文档人员，测试人员共同劳动的成果，如果说程序员没有会计基础，他就很难
搞明白“加权平均法”和“移动加权平均法”的区别，MIS系统是需要很多的行业知识的，试想
，没有财务领域的专家，只靠程序员，能够做出“管家婆”这样的软件吗？可能有的程序员看到
管家婆的界面，会说，这个我也能做，但是，界面后暗流涌动的数据流向，数据处理方法大家能
清楚吗？陆游说的“汝辈学作诗，功夫在诗外”应该就是就是这个道理。
所以说，我们做MIS的不必以此为自卑，我们可以自豪的说，MIS不但在软件工程方面有技术
含量，并且，我们通过作MIS能够成为领域专家。
众所周知，Delphi最拿手的就是作MIS，各位dfw对此有何看法，请畅言。
]
有时真想做掉他