磨刀不误砍柴工，聊聊旧系统升级改造那些事儿-InfoQ

PCon全球产品创新大会（北京站）来啦～了解最新日程了解详情 



 写点什么

记得刚刚工作的时候，头儿告诉我说，程序猿三件宝：文本编辑器、VBA、正则表达式。熟练使用一种文本编辑器，学会 VBA 和正则表达式，会给你日常工作带来很多便利。正如我们当时所在的 w 项目，很多代码转换，因此有着大量的文本处理，需要统计，发现相同问题的代码要写 VBA 工具去批量改正，这个时候用文本编辑器的行编辑功能就能很快把相关文本修改成相同格式便于用 VBA 工具做进一步处理，从而提高效率，减少手工修改带来的手误。

在前面讲到在系统升级改造的时候如果涉及到代码的统一转换升级，制定了相关的代码转换规范，当代码格式命名足够规范的时候，通过开发工具，将特定格式的代码根据相关规则了转换成相应的代码，是能极大提高转换效率的。就如同我们在 W 项目里面做的，将 COBOL，JCL 和 CICS MAP 文件进行转换，IBM COBOL 转成 MF-COBOL、VSAM 文件操作转换成对 Oracle 数据库的代码，JCL 转换成 bat 批处理文件，CICS map 转换成 jsp。通过 VBA 工具的开发，将重复机械的代码转换变成工具自动化处理，并标示出那些需要手工修改的地方，它能在几分钟内将上千份源代码文件处理完毕。

从上图我们就能看到在这个项目的代码转换过程中就使用了 COBOL 转换工具和页面转换工具，将需要修改的代码进行相应的转换，以适用于下一流程的工具所需输入。在此项目当中我们开发了各式工具超过 30 种，这些工具有力的支持了我们代码的转换工作；甚至在当时项目未采用 bug 管理系统的时候，所有 bug 都是使用 excel 文件进行管理，但一个个文件难以详尽统计其分类，查看其修正进度和具体原因，于是我们又开发了统计分析 Bug 报告的统计 VBA 工具，通过使用 VBA 读取标准的格式下的报告，进而统计输出我们所需的报告。

对于项目工具的开发，有着以下几个步骤：

工具的开发对于软件开发来讲，我们都是站在前人的肩膀上前行，如同各种各样的框架，它们也是工具，因此学会使用工具，进而创造工具，甚至开源自己的工具以造福更多人。在项目开发的过程当中通用工具的开发，往往已经成为项目核心成员每天要做的工作，在解决项目痛点的同时，提高劳动效率和降低项目风险有着关键的作用。

如同我参与的一个 GIAS 级项目，在转换客户的客户化程序的时候，客户出于方方面面的原因未及时提供原有系统界面截图，导致我们转换后的页面无法知晓其原有页面布局及相关需要显示的字段，是的客户化程序的转换停滞不前。我基于前面 W 项目的工具开发经验，使用 VBA 开发了 RPG MAP 转 HTML 的工具，解决了客户不能提供具体程序截图的这一问题，使得项目能够继续推进。

在大公司里面，开发工具更是作为一项重要任务，但切忌用力过猛，在合适的场景下它是工具，在不合适的场景下，它也许会成为项目的障碍。我曾参与了某公司的一个代码生成工具的开发，开发它的目的为了解决公司项目开发当中的一些共通问题，比如因为业务变化快，数据架构师改了数据结构，程序代码来不及改。它主要功能是将 ERWin 生成的数据结构生成对应的 java 代码，SQL 脚本，配置文件等等，且在经过少许配置就能运行的工程，类似 Spring ROO 这样的生产力工具。这个工具想法很好，从 V1 一直做到 Vn，经过了 1、2 代开发，大家觉得还不错，前面 1、2 代在公司项目当中也做过推广，有些许使用的项目，反馈并不是特别好。

于是项目架构师开始构建新一代的工具 Vn，前前后后做了两年，效果也出来了，很多地方确实达到了之前预想的结果。但是我后面发现没有项目愿意用它了，没有了上层的推动是一方面；在另外一方面，做的过于复杂也是其不受欢迎的原因，使用者需要花费较长的时间来学会使用它，而且它生成的代码过于复杂在调试的时候尤其不便，做成了大而全的东西，相当于原本我们只需要一个小小的手推车，结果他给你造了一辆重卡，虽然能满足你的需要，但是使用成本维护太高，且学习曲线还陡，没有我们项目的人对其进行培训，其他项目的成员难以自行使用。

重复造轮子本身没有错，造合适的轮子才更有意义。大公司有钱可以任性，采用跨国团队开发一个巨无霸工具，虽然某些指标比流行的 ORM 框架要好，但到头来却没有多少项目采用，未免令人唏嘘。

因此开发工具亦有以下几条值得注意：