这两天做了这样一件工作：把一个系统中(且成为B系统)的excel文件（DB定义文件）的相关信息（DB项目）抽到一个excel文件中，然后进行出现次数的统计。

统计是excel的长项，抽出来数据之后，用countif公式一统计，项目的出现次数就统计出来了。

所以这个工作的关键是把DB定义文件的内容抽出来。

而关于抽出DB定义文件，A系统已经用vba做了一个工具。

最初想象把这个工具直接拿过来用或者改造一下可能很快就搞定了。

但是这么想，显得过于简单了。

拿着工具先试跑了几个B系统的文件，

出来的内容惨不忍睹。

基本上没有正确的。

打开VBA的代码和B系统的DB定义文件一看，两方根本不吻合。

于是修改了一通VBA的代码，当然主要改的是取项目的位置。

完了再跑，还不错，出来了不少内容，只有个别错误。这些错误比较明显，很快找到相应位置的代码，修改了。

B系统的DB定义文件非常多，分了很多目录。

第一个目录好像没问题了。

试跑第二个。

（其实可以直接一下子跑完的，但是全跑的话数量太大，所花时间比较长，而且因为出来的内容多，找问题也不太容易，还有即使找到问题，定位也需要花费更多的时间。所以分开试跑，是一个折中的好方案。当然因为每个目录文件数是不一样的，所以这个办法没有二分法的效率那么高。算是一种模糊的高效方案吧）

果然出问题了。

直接在代码上报了错。

原来是每个文件都取一个固定sheet名的内容，但是不是所有的DB定义文件都那么统一。想骂娘但是没用，最简单的办法，把出错文件的相应sheet名给改了。

然后单独把出错的文件跑了一下，OK，说明对症下了药，病好了！

继续跑那个目录，还有类似的问题。

改之，继续跑。

终于没问题了。

马不停蹄—下一个目录。

文件不多，一次通过。爽！

又跑了几个还行！

前方预警！下一个目录下面有好几百个文件！

咱也不惧它！先跑一下！

跑起来了，还挺顺畅！

哎，停了！

跟上边同样的问题，改sheet名！

改一个，又一个，然后然后又一个！

高效起见，先打开文件，看看sheet名。能改则改。

忽然发现像总东西招引的蚂蚁，太多了。

Wuyangwuyang一片。

估计后面的目录还有啊。

这改下去不是办法啊。

网上查有没有好办法。

好像没有根据关键字和通配符或者正则表达式去匹配相应的sheet名的。

只能自己想。

遍历sheet名，发现通用的名字就结束。

遍历完了没发现通用的名字，就用不是最通用的那个名字。

虽然花了点时间，但是因为有编程的底子，时间不算长。

试跑了两三次，因为改了附近的一些代码，导致除了问题。

尤其是加的循环里面用的循环变量跟后面取值设值的变量一样，影响了后面的一些结果。

不过这些都是不大的问题，很快摘出来了。

试跑。

这个目录终于正常跑出来了。

验证一下。

实际有239个文件，却只出了236个表。

那三个被狗吃了？

用excel公式找出实际文件名和出来的表直接的差别，明确了那几个文件的没出。

然后把这三个文件找出来，放到一个新建的目录中，试跑。

果然出不来。

Debug。

很容易发现了问题。

原来它的位置跟以前的位置不一样。

所以表名等没出来。（相关项目出来了一部分）

改之。

因为这几个文件特殊，为了减小修改量，把这个文件作为一个特例去写。

追加了一个专门针对这个分支的取值设值方法。

还好！第一个表OK。

第二个表跟第一个表有类似的问题，把追加的条件修改一下就好。

这中间除了其他的问题，一个是日文的内容copy到vba的编辑器中，变成了乱码。

而把sakula（一个日文的文本编辑工具）的内容copy到excel或者写字板或者vba编辑器中，都会变成乱码。

这个问题困扰了很长时间，问了一个技术大拿，说这个问题很早就有，没有好的办法解决。原因是在copy日语内容的时候，实在英文输入法的前提下copy的。

只要换成日文输入法就能正常copy了。

一试，果然。神奇！

但是接下来的问题有点麻烦。

第二个文件除了跟第一个文件有一样的问题之外，还有一个问题---它出了很多空项目。

原来以为这个文件有一个包含出力sheet名的sheet名，但是删了这个sheet照样出力。

后来想想估计是虽然后面没有项目了，但是实际上有些项目不为空，所以导致它照样出力。

问了大拿，让录制ctrl+pagedn的宏，然后看看它生成的代码，并利用其代码，修改要循环到的行数。

试了下，果然生成了代码。

因为vba经验不多，所以试了几下，然后网上查找了相关内容，终于写出了相应的代码。

但是屡次实验，都没成功。

甚至几次因为取到的行数是excel的最大值100多万，直接把excel跑的无应答了。

只能杀了进程，然后继续。

又改了些代码，又上网查，又改又试。

终于解决了。

一片欢喜，意思疲惫。

简单总结：

1，意想不到的事情总会发生。

不是说A系统有个工具，B系统拿过来最多一个小时一跑就ok了。

总会有意外。

意外从不会缺席。

B系统的文件结构和A的不一致，B系统本身的文件的结构不一致，文件sheet名不一致等等都需要花很多时间试出问题，解决问题。

而这种时间在项目中还是比较常见的。

所以做预算的时候，必须考虑意想不到的事情，必须考虑这些是按发生的时候的时间。

不然吃大亏。

2， 类似这次的工作，更大的成本在于因为标本（DB定义文件）的庞大以及事前未知的不一致导致需要大量试错。

当然试错的方法实可以讨论的。应该有一定的方法论。

3，标本的不一致导致的试错时间，检查时间及解决时间是非常巨大的，并非修改几行代码或者修改一个标本或者对所有文件进行一次工具的运行的时间所能比的。

这个时间甚至是几何增加的。

4， 解决问的时候有时间会引发新的问题。

所以要注意尽量减少新的问题的发生，尽量避免改一个问题的时候改出来一个新的问题。

另外新问题的解决也需要花不少的时间。

5，解决问题要明确问题的真实现象，并进行一步一步追踪，以期最后找到相应的解决方案。

比如在试最大目录的几个问题文件时，发生error时，对象DB定义文件是打开的，我再把目录下的文件拷到另一个目录的时候，这个开着文件除了自己会被拷过去，也会把自己的临时文件拷过去。

着就会引发相应的问题，比如读到这个文件，但是名字和正常的名字不太一样，导致程序的某个地方出错。

认真明确现象，一步步追踪，基本上离最终解决问题就不远了。