我的天

已经放了两天的假，但是这两天我依然不得不跟工作有紧密联系。9月30里的晚上，从8点多开始我就在忙工作，虽然其实单位的业务是9点多才结束的，但是能干的那些我都已经先干了，但其实我又没有全部干完，但即便这样的话，还是干到了晚上11点多。之所以没干完，并不是因为我差那么点时间，而是我觉得我得主动变得不那么主动，因为我把别人的事情都干完了，别人就不知道干什么好了。所以没干完那些事是我故意留下来的。但实际上把那些事干完才算是一个完整的闭合，能保证数据准确。

这个月末是我第一次用某个VBA的脚本自动给我粘贴那些量不少，但是没什么营养的东西，起码对我来说是没什么营养的，但是上面就是需要用某种格式输出让他们看到。过去几年我都是人肉进行格式的转换，然后人肉进行复制粘贴，上个月末我来不及做出来，但是思路已经有，所以在月头的时候我就已经把这个做了出来，试过没有问题，但我不确定使用的时候会不会还有bug，结果如我所料，的确是有bug的，其中一个包非常的无语，是复制粘贴没对上位，为什么测试的时候没有看出这个问题我也不知道。另外一个不能说是我的bug，因为数据太小了，如果是四舍五入保留三位小数，那个数在三位小数以外，所以就被零处理了，但实际上那不是0。最后一个bug，其实之前我也遇到过，那是一个关于替换时选择关键词的东西，在什么时候替换？关键词是什么？如果用一般的思路去考虑，就是那样，但实际上选择那样的关键词不准确，所以最终替换出来的不是我想要的东西。

总的来说，这三个bug虽然存在，但要纠正过来还是比较容易的。对我这个写脚本的人来说肯定是容易的，因为我知道那个思路是什么，虽然已经隔了一个月，具体不再那么清楚了，但是我还在我还是很清楚当时自己用的大概是什么样的方案。如果这个第一次不是让我遇到了，而是别人遇到了，这样的bug，可能就比较郁闷，最终就可能只能用回我以前的老方式，人肉去做复制粘贴和数据汇总。

8月我花了很多时间写VBA，9月份我花了大概一周的时间做统计分析，然后又花了一周多的时间去学习《深入浅出统计学》，然后接下来就进入了疯狂的月末。因为同事出去学习了一周，9月的最后一周又是跟中秋国庆假期关联的，同事提前两天请假回家了，所以我感觉后半个月好像有很多事，好像一直都很忙，实际上也的确这样，因为单位的业务仿佛进入了疯狂的高铁模式，而且是悬浮列车的那种。几乎可以这么说，完全突破了我的想象力，无论是车还是船，作业的数量都是让我觉得是空前的。为什么一天居然可以整那么多车？为什么装的那些船永远都装不完？每天作业的仓号最多的那天有19个。明明某个客户一天就只出那么几千吨，但是每天都起码有5个以上的仓房在进出。每个客户一个仓房，但是有很多个客户，又或者只有几个客户，但每个客户都动很多个厂房，这两种情况都会让我抓狂。因为这意味着明明作业量不大，但需要做很多个汇总数据。

但总算这个9月我挺过去了。

写VBA的这段日子，我觉得自己的脑子越来越习惯用那种方式思考。如果你要把一件经常做的事情程序化，你就得抓住一些关键点。虽然流程大概差不多都那样的，但实际上人在操作的过程中还是有一些关键。如果想把那些流程标准化、自动解决问题，你就得把那些模糊的关键点全部都明确，比如看到什么关键词进行什么操作，这得一清二楚，而且这些关键词的选择还得考虑不容易被干扰。这些关键词的选取对一般人来说是没什么概念的，他们觉得大概应该那样，但实际上你要在一堆东西里面选取关键词，绝对不能像在一些标准序列里面选其中一个那么自然。

有一天同事发微信过来说我上报的某个数据好像不对，因为他筛选出来的结果不是那样的。我不知道为什么会发生这种事情，因为在上报那个数据之前，我已经再三核对。又过了一段时间，他又发微信过来告诉我，是他筛选的时候出现了一些干扰项，之前他没看到。他在去向字段筛选的关键词是Q3，理论上那是一个仓号，对绝大多数人来说，如果只说这两个字，也会觉得这是一个仓号，但问题是那天刚好遇到某个车的车牌里有这个Q3这两个字，于是他筛选到的结果跟我计算Q3的数量当然就有区别了。这个时候，如果他筛选的关键词不是Q3，不是Q3-01就不会有这种问题，因为没有一个车牌会有“-”。如果他选的是Q3-01，那么那些Q31、Q35的仓号也不会干扰到他的筛选结果。我不知道浪潮那些筛选项是如何设置的。如果是以前的那个系统，以前的那个需要运行exe的系统筛选，你还得选择到底是什么形式的筛选，是等于大于还是包含。现在浪潮那个在网页上运行的系统筛选词就只是模糊匹配。如果去向那里必须精确匹配，你不写Q3-01就返回不到你要的结果，他也不会遇到车牌号这种事情。把车牌和仓号按照流向放在来源和去向，从一开始我就觉得这很逆天。如果一开始就给我这样的数据，最后我还得通过入库和出库去判定到底哪个是车，哪个是仓。如果我的同事查找数据的那个界面没有这种来源和去向，只有流向、仓号、车船号，显然他一定会在仓号那里选Q3，而不会去车船号那里输入Q3，这样的话也不会遇到他碰到过的问题。

对编程的人来说，尤其是对那些专门要把某些程序自动化的人来说，非常在乎关键词的选择。因为把一些老表格自动化的过程中你会发现那些东西根本不是标准的字段模式。要怎么把那些非标的东西标准化，你就得绞尽脑汁选择关键词，怎么才会不重复？怎么才能实现你的目的？当然了，之所以这么说是因这些标准化是基于Excel工作表的，如果那本来就是一个数据库里面的东西，即便他们不愿意标准化，有些东西也不得不标准化。

当你强迫自己以某种方式去思考以后，经过一段时间的锻炼，你会觉得自己在不知不觉之中有了那种条件反射的能力。

当我正在潜心研究VBA+ADO+SQL的时候，某一天当我去搜索某个问题的解决方案，发现Excel里将要内置python了。那这个到底是什么样的python呢？星期四的晚上我看到ExcelHome的专业人士进行了进一步的解释。他们的专业人士说的东西，我还是比较认可的。

当我第一次听说Excel里面终于可以用python的时候，我并不太兴奋。为什么会这么说呢？因为是在Excel的某个地方写python，而不是在一个完备的IDE里写。这有什么问题呢？

可以这么说，Excel所有写代码的地方都让人挺不愉快。比如你要写公式，经常的情况是你选了那个，一会车，然后就没有了。如果你要写嵌套的公式，那些括号更加是会把你搞死。写公式的那个地方，你很难分得清全角和半角标点符号，于是你经常被卡在那个地方，然后被卡没了才发现自己在打勾之前没有先复制粘贴到其他地方，所以打那一大堆全部白费了。

在其它编辑器里也很郁闷。PQ有高级编辑器，高级编辑器好像要比公式智能一点点，但是又过于智能了，比如经常会帮助你自动添加一些符号，有可能是双引号，更多时候是逗号或者括号，但那并不是你想要的，你自己会把那补全。在你不知情的情况下，PQ给你添加上去以后，最终就报错了，翻找一大堆后才发现，那里不知道为什么多了一个符号。

PP里面写公式，如果是写度量值，情况还会好一点，因为你可以先做一个公式的校验，校验失败起码就意味着你基本上不用确定提交了，但是校验的时候到底是哪里不对，为什么不对呢？这得凭借你的经验。如果你进入到PP里面，在那个类似于Excel写公式的那个地方写代码，经常遇到的情况是你还没写完，就直接给你报错。因为报错了，你被卡住了，所以还真的漏了一些东西，结果当然是无果了。

相对于PQ和PP来说，VBA算是Excel里面可以写代码比较完善的地方。在VBA里有标识符和关键字，而且可以设置不一样的颜色，但问题是VBA那个编辑器除了会帮你增加空格以外，你别想能帮你进行任何的补全。无论函数名称还是那些你之前已经定义过的变量。被大家吐槽的最多的是一句判断没写完，要到其它地方复制东西，马上弹窗告诉你语法错误。当你运行不通过的时候，会有各种各样的弹窗，但绝大多数情况之下提示都没什么意义，因为没有针对性，你不知道该怎么改。

综上所述，在现有的Excel里面写代码，除非你非常牛逼，一写就对，万一你是那种粗心大意到极点的人，在Excel里写代码会让你非常崩溃。那个大家期待已久的python，据专业人士说，输入的方式是盲打。你别想Excel会给你补全，会给你提示任何错误。而且那个python in Excel是云上的东西，所以你的电脑上可以完全不安装python，数据通过网络云计算然后再返回结果。这就意味着算力最大的障碍就是你和服务器之间到底有多通畅？VBA完全可以脱机使用，那就意味着可以秒杀出结果，但如果我用的是python，需要实现同样的功能，我跟云服务器那边用有几万光年的代沟，甚至根本连不上，那么python那个地方永远都会显示#BUSY#，永远都不会有结果。如果一直挂在那里，或者某一时刻终于连上了，就会把结果反馈回来。我从来不太相信微软的服务器，因为从windows或者office软件系列的更新就可以看出，我们跟微软的服务器有非常深的代沟。现在这个刚刚有了雏形的python，居然是暂时只能用云计算，这样的东西能让人有多少期待呢？如果你不是在中国，如果你在美国，你是一个Microsoft 365的付费用户，而且是专业版的。可能会好很多，但是，我们在中国，我只能说希望越大失望越大。

我还是用好手头上的工具，实现我的小目标好了。

每次都定下一个小目标，然后去实现。结果发现一天多一点的时间居然就能搞定一个问题，这种进度有点出乎我意料，因为之前的那些问题让我挣扎了好长一段时间，起码有两三天，之所以后来进度加快了，大概是因为我明了了我要做什么，但是尽管是这样，还是会遇到很多奇奇怪怪的问题。

这周初我解决的是批量生成月度核对表。我把这个任务分成两个步骤，一个是查询到底要生成多少，接着就是把查询到的结果生成文件，但是那个结果跟文件又不一定是完全对应的，根据不同条件可能10条查询结果最终会生成9个表。因为实际上某些条件是需要合并才能得到我想要的文件。在怎么设定条件，如何进行循环方面，我纠结了好长时间，几乎可以这么说，上个周末我一直在做各种尝试，为的就是最终实现这个目标。

在完成了批量生成月报以后，接下来我要做的是生成某个仓的分仓台账。相对于之前的月度核对表，这个单仓台账相对而言条件是固定的，而且必定只生成一个文件。同样我首先做的也是做一个查询，查询一下这个仓到底有多少条记录是可以生成分仓台账的，我又要生成具体哪一条。有些是无法自动实现的，因为实际情况是某些仓某些筛选条件是不一样的，但实际上应该反映在同一个分仓台账里。这个时候就需要手动合并一下条件。这种例外的事件不确定会在什么时候发生，所以必须给手动留有余地。之所以分步骤，其实一个很重要的原因是其实有时并不是为了生成分仓台账，只是要查询一下这个仓的情况。批量生成月度核对表，我花了好几天的时间，但是生成分仓台账，我只花了一天不到。

接着，我研究的是库存查询。在不同的条件之下进行库存查询，最后的结果是以一个透视表的方式展现出来，根据不同的查询条件透视的项目不一样。虽然我想到透视的项目是不一样的，但实际上在我研究的过程中，我先在单一的条件上做尝试，当单一的条件生成的数据没有问题以后再把它扩充到动态条件。因为有了之前月度核对表的锻炼，所以动态条件该怎么做我是有点底的。

SQL最基本的查询语句基本上我已经比较熟悉，这一次库存查询最后一步需要做一个透视。透视这个东西是我之前没有尝试过的，虽然我是Excel数据透视表的超级粉丝，但是在SQL里面控制这个东西，我还是很不在行的。所以到底什么条件可以控制，可以控制到什么程度我是不知道的。教程通常都只是最简单的那些，用上面的数据你重复100遍都不会出什么幺蛾子，但是在实际情况下你会有更多需求。比如当我要控制被透视列的排序的时候发现好像在Excel的SQL里无法做到。即便我在透视之前那一步已经排好序了，但是透视的时候依然是我行我素。让我比较挣扎的是，在透视之前我已经通过分组合并计算出被透视的列的合计数了，但是透视之后合计混在了那一堆被透视的字段中间。最后我已经想到不计算合计，在SQL里面生成透视以后输出到数组，我在数组里面做合计。就在我几乎要放弃的时候，原来合计可以通过在透视的select里用一个聚合函数实现，这样的话透视之后的表格就是先是条件列，然后是合计，接着是那些被透视的列。虽然合计不是放在我想要的最后面，但起码放在了最前面。

库存查询研究过程中让我纠结的问题是什么，明天继续。

实现功能，我觉得只是最基本的要求。接下来我会考虑到底有什么是可以优化的，比如如果我做了很多个判断，我能不能少做一些，把那些判断合并起来或者里面我做了不少循环，循环通常是为了赋值，赋值完以后我有没有立即就把那个数组或者字典之类的释放。我不知道那些东西释放跟不释放效率会不会相差很多，但可以肯定的是，如果我在一个脚本里同一个数组或者字典的名字被重复用多次，而在使用之前我又没有重新定义，在上一个数组或者字典使用完毕之后，把它清除干净会让我安心很多。

一开始要实现某个功能的时候，我都是写完一大堆，然后发现另外一个功能可能就是在那一大堆里面改一点点，然后就可以实现了，我就会把那一大堆复制粘贴，然后改一点点，发现的确是可以的，但是当这个脚本真的要放出来的时候，我就得合并同类项，能不能把这两个东西通过以某个判断把它们合并在一起呢？如果那两段话的差别就只是某个条件判断不一样，我能不能把那个条件判断放在前面，然后把判断结果赋值给一个变量接着后面就可以在同一段话里面引用那个变量了。这样的话从脚本的体积来说可以缩短很多，起码可以减肥一半，甚至更多。

一直以来我都想不通，如果我要从一个工作簿里复制某个工作表到另外一个新的工作簿。那么我是应该把整个工作表复制过去呢，还是说在新的那个工作簿里面新建一个工作表，然后把原来那个的内容复制到那边。在生成这篇blog的时候，其实我依然没有做过这种尝试，到底哪一个的效率会高一点呢？我选择的是直接把工作表复制过去。当我全部复制完毕以后，因为每个工作簿新建的时候都会有一个默认的工作表，我最后的步骤就是把默认的那个工作表删掉。但是让我想不明白的是，如果我不是在VBA里操作，而是直接操作Excel，我在某个已经打开的工作簿的工作表的表名那里点右键之后选择在新的工作簿里面建立这个工作表的副本，那么新的工作簿里是不会有默认空白工作表的。这是不是证明，如果我在新建工作簿里面设定某些参数可以不让那个默认空白的工作表生成呢？因为如果这样的话，我就不需要在后面再做一个删除的操作了。从数据上说，删不删除都无所谓，因为那个是空白的，但是对完美主义者来说，总觉得有那么一个空表实在很碍眼。

当我终于实现了批量生成文件以后，我发现批量生成文件的速度很慢。慢到大概每个表都需要一秒钟，如果要批量生成9个表就得9秒钟甚至更多。在考虑如何缩短时间的时候，我马上想到我把那些批量生成的表全部都放在一个工作簿里，事情就变成了批量生成一个工作簿里面的N个工作表，而不是生成N个工作簿。接着我发现这样的确能提高一点速度，如果要生成9个表的话，时间会从大概9秒钟下降到6秒钟，但是我觉得还是不行。于是我就开始研究我这个生成的过程到底有没有什么地方可以改进。因为之前我的策略是生成9个工作簿，所以我肯定是从原始的文件里先把自带格式的工作表复制到新的工作簿，然后再把新的数据粘贴到新的工作簿，然后保存。同样的思路，用在一个工作簿的N个工作表里，效率很低。所以接下来我做的就是新建一个工作簿，然后把带有格式的工作表复制过去。接着在新的工作簿里面复制里面带有格式的工作表，改名，接着在新的工作表里赋值。这样最大的区别就在于在多次复制工作表的时候，我不再需要跨工作簿了。这么一个不跨文件的操作，直接让批量生成的时间从6秒下降到2秒，效果非常明显。我觉得两秒也几乎基本上是个极限了，因为即便我用最简单的循环，基本上不在工作表里面录入什么数据也需要接近2秒的时间，现在我粘贴了那么多数据，还有就是生成这些数据之前还进行了N步操作，整个过程下来不到三秒，我觉得完全可以接受。

追求更快更好是从来没有尽头的。