我的天

习惯了用VSCode写python以后回到VBA，感觉怎么整怎么都不对。首先相对于python来说，VBA的编写规则好像有点八股，因为那些专有名字总是老长。有一些让我想不明白的是某些东西为什么就不能先存储在某个地方，往后在别的地方调用？比如复制，理论上是很简单的事情，就只是从这里到那里而已。在python里，你喜欢怎么整就怎么整，但实际上你要用VBA控制Excel，做一个复制，远远没有你想象中的那么简单。对python来说，数据是没有格式的，没办法决定这一串数字到底是什么颜色、什么字体、大小、背景是什么，但是Excel的单元格有这些东西，你要复制一堆单元格到别的地方他默认就会把所有格式都带上，但实际上你不过想贴一个纯粹的文本或者数字而已。因为这样你还得在复制粘贴的时候用上其它东西去强调说明，而一旦有这个强调的操作，这就是一个特殊的复制粘贴。复制英文是copy，如果你直接把一堆单元格copy到另外一堆单元格，就会把所有格式都一起带过去，如果你不想干这种事你只想要数据本身，你就得把你原来的那部分单元格select，然后对select的部分做copy，最后在其它需要粘贴的地方再用特殊的粘贴方式。所有人都觉得最直观的方式点copy，当你要实现最纯粹粘贴的时候却无法做到。

copy本身很简单，是我们理解的很简单，但是对Excel的设计者、对VBA所控制的东西来说，copy实际上一点都不简单。昨天有段时间我曾经想过，能不能在某个单据格式改造的时候直接在VBA里做分组，然后得出汇总。但是我又非常明白，VBA本身是没有类似pandas的那种dataframe的东西。PQ和PP都有类似dataframe的东西，所以你不需要很努力一个一个数据去处理，不需要考虑其中的数组，你只需要操控好行和列的盘曲折叠就可以了。但是在VBA里，效率最高的一定是数组，数组没办法给你判别行还是列。在增加数据的情况下，你还不能在行业里增加，你必须把行列转置，然后在列那里增加，最后再把它转回行，这个东西很绕。虽然行列转制这种东西在pandas跟PQ里都有，但是在增加行或者增加列的时候，远远没有VBA的数组那么绕，于是你就可以花更多的时间去考虑我到底要怎么折腾那些东西，而不是在数那些东西到底有多少行多少列，我要增加什么，该如何插入、得插入多少。

C语言考试的时候我也是这么被C语言的指针搞得迷迷糊糊。如果我可以把C语言的指针玩得很溜，可能我对VBA的数组操作就不会有太多槽点了。可以肯定的是，当年的我跟现在的我对数组操作都比较畏惧……

因为不想用VBA去加工数据，所以我临时干的是用PQ做汇总数据，然后用VBA把得出来的数据精确地按照需要的格式生成文件。虽然实际上这样不过是点一下变成多点几下而已，但我觉得如果我能在VBA层面就完成了汇总，我就不需要 PQ运行的那几秒钟。我抠门的不是鼠标多点几下，而是刷新PQ那几秒钟，所以我还会在VBA上努力的。

我觉得自己已经迷上了PQ，沉迷于那种盘曲折叠的状态，一发不可收拾。我不知道为什么，如果要生成某个表格的话，我首先想到的是PQ，大概是因为出来的东西相对于PP来说PQ更像个表格，但是PQ又不是一个普通的表格。虽然到现在为止，我还没搞清楚到底限制PQ性能的到底是什么。还有另外一个让我很抓狂的是我在PQ的高级编辑器里面写了好多东西，除了进到里面复制粘贴以外，我还可以通过什么手段获取那些脚本呢？若某一天我换上了个低版本的office，可能用不PQ，所以我可能需要用Power Bi来代劳，那个时候如果得把脚本一点一点贴过去就实在太痛苦了，有没有一个脚本导出的方式呢？虽然实际上我问这个问题是因为其实我也没搞清楚如果我在某个Excel文件里面设置了宏，我该用什么方法把那个脚本复制出来。毕竟实际上Excel就是一个幌子，脚本才是最核心的部分，同样的疑惑，我在PP上也有。所以，微软到底是怎么想的呢？实际上无论是PQ、PP还是VBA，最终都是用某些脚本去控制Excel本身。把那些脚本在这个Excel可用，在另外的Excel也可以。我自己用VBA的习惯，就是喜欢把脚本都丢在某一个下文件里，那个东西里面什么都没有，只有脚本。当我打开这个文件，我再打开其它文件，我就可以在其它Excel文件上运行我想要的脚本。所以实际上那些脚本是些独立的东西，我甚至可以觉得，如果脚本编辑器能单独放出来，把文件拖进去以后就可以直接展示结果，有可能是直接把最终数据展示出来，也有可能是生成一个文件。对于小型的图表直接展示数据显然是最方便的，但是对一些比较长篇的东西，直接生成一个结果文件才是我们想要的，但是Excel没有把这个脚本控制器单独放出来。根据我自己的运用习惯，我觉得把PQ、PP跟VBA一起单独，变成一个就像Word、Excel、PowerPoint之类的独立 office套件完全说得过去。但显然，可能微软并不想这么干，因为一旦这样把高深的东西都暴露出来，很快就会被抄袭。因为实际上这些功能并不是office这三剑客独有的，其它编程软件也能实现。还有另外一点就是显然三剑客不是给普通人用的，因为对一些很新很新的手来说，Excel甚至不是用公式的，而是用来单元格加单元格加单元格获取结果的，还有就是把单元格设置成手动彩虹的颜色。如果那里用的是条件格式的色带我觉得很靠谱，但是某一天当我看到某人Excel设置成手动彩虹的时候，我彻底震惊了，他们直接把Excel变成了画板。

不是人人都会着迷于编程，但因为我的算力不好，我老会粗心大意，叫我一个一个单元格叠加，加这加着我就点漏了。所以我得让机器帮我做重复的工作，而我则躲在远远的控制端负责发号逻辑命令。

又是投篮的第2天，我又没有做任何的运动，依然是坐在那里，整个晚上都把心投在Power Pivot上。但这一次我没有上一次那么好运，可以解决困扰了我很长时间的问题，整整一个晚上我都毫无收获。增长的只是我越来越不知道自己在做什么。但跟前两天相比，我没有一直都耗在那里，而是给自己划定一个底，超过那个时间我就回宿舍洗澡睡觉。在睡觉之前我拿出架子上的另外一本关于Power BI的书，之所以我说那是Power BI，因为那本书大半本都在说Power Query，有部分章节是说Power Pivot，然后是二者的融合。但话说回来，我又不能说那是Power BI，因为那本书是基于Excel而不是Power BI的。

就公式参数的复杂程度来说，我感觉PQ要比PP麻烦很多，尤其是虽然你看上去PQ的界面就只有那么几个按钮，但实际上要发挥 PQ的所有潜能，所有东西都必须在高级编辑器里面完成，尤其是一些非常高效的操作。有些结合的步骤，或许你觉得高级的步骤结合起来跟分步没什么区别，的确对一些一般操作来说，这是可以做到的，但是某些步骤必须层层堆套，而且公式里面的参数有很多的时候，让人感觉脑子就不好使了，从表到列到记录到具体数据。以前我曾经死磕过PQ，觉得非常强大，也非常烧脑。经过一堆操作以后，的确可以做到想要的效果了，但问题是其实那样的效率并不高。所以最终我没有采用PQ的方式，而是直接自己写VBA。相对于 PQ而言，我觉得VBA返倒更符合一直以来我学习其它编程语言的思路，比如说一开始接触到的C又或者后来接触到的Python。但和Python相比，VBA里面有很多默认的公式套路，但起码VBA里的公式套路还可以理解，而不像PQ那样复杂到让你觉得望而生畏。

PP让我觉得很烦恼的地方是可能它就那么几个函数，但是它的组合方式却是千变万化的。你可以用同样的代码在不同的地方放置，但效果完全不同，你也可以写完全不一样的代码实现同一个效果。当然，更多时候你想用一堆代码实现某个效果，但是别说出效果，你通常会被卡在公式审核那一步。我觉得PP让我绝望的地方在于我还没办法以它的思路分步执行，我无法预判如果我这么写的话会达到什么效果。当然这只是一个初学者的烦恼，当我把所有规则都烂熟于胸之后，我觉得这一切都不再是问题。PP我觉得是一个我必须越过去的坎。因为那跟大数据有那么一点关系，虽然这又跟大家说经常听说的那种大数据有很大区别。对我来说，几千上万条数据已经是大数据了。当这些数据经过这种盘曲折叠以后，最终的量可能是数倍甚至以次方的形式增加。我小小的脑袋瓜当然不可能预判出这种事情。

大概我现在的这种烦恼，我有一种方式能稍微缓解一点，就是放下自己手头上要解决的问题，纯粹只投入各本教材中最经典的简单案例。当我把那些都融会贯通了以后，再开始DIY我的方案。

我花了三天时间（但实际上每天都只有半天时间）把二维报表提取数据成以一维数据表。这有什么难度呢？一开始我也认为好像难度不是很大，但开始琢磨以后我发现事情远远没有我想象中的那么简单。我用的是Excel的VBA。如果操作简单的话可以在Excel的数据层面进行操作，但如果我要进行大量的数据清洗显然为了要追求效率，就必定要用到数组，数组这种东西无非就是不断地叠加循环以及判断。循环和判断我觉得几乎可以这么说，是编程的核心。要实现最终的目标，首先你得有一个非常清晰的逻辑，然后用那些循环和判断实现你的逻辑。当我看到某些人逻辑彻底混乱的时候，我心里就会冒出一句话，他们绝对不会懂得编程。也正是因为这样，所以现在的幼儿教育有时会把编程列为一个非常重要的项目，实际上练习编程就是锻炼逻辑，但是逻辑这种东西又分为了既定的规则以及你的自创招式。自创招式都来源于各种规则，但是不同的编摆方式会有不同的效果。成功编程的话效率极高，是秒杀型的，但是要制造那个秒杀效果的过程可能非常漫长。

我需要处理的那个报表，准确来说是一套报表，但是用的几乎都是一个版式。虽然看上去几乎一样，但是有可能某些细节上会有不同。如果我用了一个靠谱的逻辑去抓取数据，无论什么微调，对我来说都毫无影响。所以首先我要确定我要在报表里抓取什么东西，我要用什么方式去除掉那些我不需要的东西。如果用Excel表格的思路去理解的话，我肯定是先做一个筛选，然后把我不要的删除掉。如果不要的东西在行那里我还可以用关键词筛选掉，但如果那些东西出现在列那里，难道我要先做一个转制，然后再做删除吗？更郁闷的是那个表格的表头有三行。就一个现成的要达到最终效果的报表而言，三行的表头没有任何问题，但是如果你要把它按照数据层面去理解，这就很逆天。就更加不用说这三行的表头里面还有不少合并单元格，但幸好的是当我把单元格拆分了以后，实际上每个单元格里其实都有靠谱数据的。

我的思路是先把我不要的行删除掉，然后把我不要的列再删除掉。在删除行这个问题上一步我就搞定了，但在删除列这个问题上，我花了好几步，首先是删除没有数据的列，其次是删除含有某些关键词的列，也就是那些虽然有数据，但对我来说也没什么作用的列。把可以删除的东西都删除掉以后，我进行了一个二维表转化为一维表的操作，接下来就是在那个加工完的表里加一列存放表名。之前我说过我要处理的是一组样式差不多的表格。上面说的一大通，我只是说针对一个表我需要这么处理，所以在这之前我要有一个把文件夹里所有工作簿里面包含某些关键词的工作表汇总到一个工作簿里的步骤。我觉得这个合并工作表的耗时挺长，相对于后面的数组操作来说，这实在太费时了。之所以会这么耗费时间，是因为实际上Excel需要把工作簿一个个打开，抓取里面的某个工作表，然后关掉，不断地重复这个步骤，不断地开关工作簿会非常耗时。

如果之前我没有花过很多时间在账本的合并数据上，现在突然要我整这个的话，我肯定得花好几倍甚至十几倍的时间，但因为现在我是站在曾经自己的肩膀上的，所以虽然期间有过纠结，但总的来说还算是比较顺利。我考虑过要不要进行这种操作，但过去几年我都一直没这么干，因为要合并这些数据，一年只做一遍，有没有必要开发这样一个VBA脚本去实现呢？当那个报表被国粮局修改了，我又得重新修改脚本适应。所以之前我就在那里纠结到底有没有必要进行这个脚本的开发。

最终我做了，而且还做到了。

到底我自己有多强大？即便我自己也不知道。

在对账这个问题上，貌似我的手上已经有不少的武器。那种东西是我不知道该如何积累回来的，已经成为了我的条件反射。该用什么方式才可以快捷方便而且全面，最好是扩展性也很强的。什么时候应该用搜索或者索引，什么时候应该用数据透视表，什么时候必须得上数据清洗……数据的高级应用，我很多还不知道，但现在，我已经不像从前那样只是蛮力复制粘贴了。

回想起来，10多年前当我第1次接触统计数据的时候，我用的是老员工留下的人工透视法。显然在手抄账的年代，那个东西非常直观。当时，李大姐的那个东西用了好几页纸打印出来，然后粘贴成一大张，我简直震惊了。上面的所有数据都是手填，万一我手贱了呢？每年的日期就那么多了，我们的仓会不断增加，我怎么能保证每个都不错？当时我没有想过可以用什么其他方法可以实现同样的事，我也没想到可以不用那样。怎么才能不人工？

那个时候我还不认识数据透视表。现在我觉得，数据透视表大概是Excel里面性价比最高的东西，那个东西是用来快速得出汇总数据的，但如果原始数据不规范，数据透视表就无从谈起。近些日子我又认识了Power Query。那个东西最擅长的是数据清洗，当然也可以把汇总数据一步到位，但是汇总数据这个活儿，我觉得PQ在处理不规范数据上用处更大，至于汇总数据这种事情，交给数据透视表就挺好，毕竟数据透视表可以随心所欲各种变换，而PQ一定程度上是在做脚本编写。如果只需要某个固定的最终结果，PQ一步到位，但是如果不确定需要的汇总结果，数据透视表更省事。因为数据透视表建立了，低手也能得出结果，但PQ这东西，高手写出来的嵌套公式，低手绝大多数时候都无法参透，即便你耗费很多时间奢望理解。没有一定的基础，PQ就是天书。现在，我仍然需要10年前那种用手工透视的效果，但我用的方法肯定不是人工透视。一年365或366天是固定下来的，但是随着仓数的增多，那将是一个无底洞。万一平房仓需要分堆垛了呢？那更加复杂，别说一张A4纸，即便是10张A4纸拼接起来也未必能表达得了。换句话说，如果10张A4纸拼接起来，我看完前面，再看后面，确定我在填写某一行的时候会不出错吗？

有些人只会延续前人的方法，埋头继续做。一开始的时候，我也是用前人的方法，但做着做着，在不知不觉之中我就改进了，最后得出了一套我自己的方法，我不知道这是不是最优，但我的方法可以让我得心应手，在提升质量的前提下，大大简化之前的操作。当我想让某个固定程序更方便的时候，我会直接写个脚本。现在我用的是VBA，或许以后我会用python。VBA是所有office软件都具备的功能，但python这种东西必须得电脑装软件支持。如果只是一个人使用，完全没问题，但如果数据需要多人协作，显然这样就有点不方便了，因为不同软件的版本可能会有一些意想不到的小插曲。

我在五行之中过日子，但我也必须跳出五行提高境界。