我的天

我觉得编程会让人上瘾，尤其是当你实现了自己的目标以后，你就会有很多想法，比如之前我已经做过，而且已经实现了东西，能不能更进一步，再改进一些，让程序跑得更快一点？一开始的时候，只要能实现某个功能就可以了，无论用的是什么方法。在这个初级阶段，我是不会考虑别人到底行不行的，反正我行就可以，但是当自己包里面的工具越来越多以后。到底要选择什么工具，也会变成我一个纠结的地方，虽然有些工具已经很成熟了，肯定能实现我的效果，但是我还会想有没有更快捷的方式呢？

我已经不记得我是什么时候开始认识Power Query了，大概是在office2016的时候吧。那个时候我觉得那个东西可以做文本拼接太厉害了，而且厉害之处就像是跟数据透视表一样，当你的原数据发生了变动，刷新一下结果就出来了，但实际上那只是教程的效果，你完全按照教程这么干，的确能出结果。还记得几年前当我要算某些库存的时候，我用了一些很笨的方法。为了要实现区间日期里面的累计库存我用了一些非常耗费电脑的步骤。本来数据的量就不小，又外加要实现这样的效果，所以真的得算上很长时间才终于得到结果。那个很长时间意味着可能要等5分钟以上，在等待的过程中，我都怀疑自己的电脑是不是死机了。后来我也有算累计库存，但大概我已经不用一开始的那些方法了。我也有试过在VBA里计算累计库存。如果是在其它软件下的SQL里，计算累计数可以有很直接的方法，因为他们有现成的函数可以套用，但是在VBA里面的SQL，貌似至今为止，我尝试成功的也就只能硬着头皮做一个笛卡尔积。如果数据量比较大，那将是一个噩梦。噩梦归噩梦，数据还是能算出来的，如果我只是算一个月的库存，顶多就是几秒钟的事，通常情况下如果业务量不大，一秒就差不多了，但是如果要算一年的数据，那就要跑上几十秒。在VBA层面需要跑几十秒，而如果在PQ里我简直不敢想象得多久。

试过VBA，试过PQ，在PQ里我知道我要什么，它的透视和逆透视功能让我省掉很多麻烦，但这两个便捷功能也会默认带出一些意想不到的反效果，比如默认透视的是来源去向，万一筛选区间只有入没有出，但后续处理又默认有出入，这就会卡住。Excel 的SQL里，透视就是最后一步，所以如果中途要实现这种功能只能通过添加条件字段，手动添加字段的好处是不会有PQ透视法的那种透视不出来后面没法干。就可控程度来说，VBA更容易，能把多个操作在一步里秒杀实现，比如修改某个字段的数据和增加某个字段，我就可以把它们在一步里实现，外加同时搞个什么排序。这些步骤在PQ里面，如果不是高级玩家用嵌套的方式，也就只能一步一步慢慢来。我不知道，PQ里面嵌套一步到位跟一步一步慢慢来到底效率差了多少。估计这会有运行时间的差别，但到底差别了多少，这个我没有研究过，因为我还没到的那种可以混搭在一起，一步到位的水平。处理同样的数据，使用类似的步骤，PQ就是比VBA要慢，我也不知道到底慢在哪里，为什么会那么慢？其实数据量不大，但关键是PQ载入的时候很容易出错，但那个出错到底是什么，没人说得清，因为上一次刷新不行，下一次刷新可能又可以了。在VBA里，除了去年年末的某段时间，我经常出现这样那样的奇怪现象，其它时候基本上行就行，不行就是不行。不会出现同一个数据，同一个宏，前一次可以，后一次不行。在PQ里可能得转上半分钟以上的事情，在VBA里非常有可能0.5秒以内就解决了。以前做字幕的时候，我就知道人的反应时间通常是0.3秒，如果一个VBA脚本只需0.3秒就能结束战斗，对普通人来说，那就是眨眼的事而已。

以前我没想过要这么干，以前想着怎么方便怎么来，但是当VBA有点上瘾了以后，我逐渐的把之前用PQ处理的东西全部都用VBA的方式再整了一遍。出来的效果非常好，干净利落快如闪电。让我觉得舒服的是VBE界面是被我调整过的，调整过VBE的布局和颜色，但是在PQ里，那个小得要死的高级编辑器字体实在让我看得很不舒服，但通常某些高端的功能只能在那里敲代码，所以这就很痛苦。

不把某些事完成，心里总会一直念惦记着，把这些事情都干完了，我就可以好好睡觉。

有时候我也搞不懂自己是不是真的有编程的天赋，还是说不知道为什么我对这方面会特别感兴趣。之所以这样，我觉得一定程度上跟我过往的经历有关。我不讨厌数学，但因为自己的计算能力有问题，经常会因为这样那样的原因出错，所以越往上学，我的成绩就越会出现提不上去。知道那个思路，但是却算不出那个答案。这种情况在某些只需要答案不需要过程的考试里面就很吃亏。即便需要计算过程，但如果我在第一个部分就算错了，后面也就没有什么意义了，因为根本算不下去。

编程好像一定程度上弥补了我的计算失误。因为计算结果是由机器完成的，而我只需要提供思路。在简单的问题上，那种百发百中的感觉真好。不过当问题遇到的越来越多，思路不是一下子就能畅通，我需要碰过很多壁以后才能出结果我会觉得刺激。在考虑很多因素的时候，总是有这样那样的不到位。有些步骤可以做在前面，也可以坐在后面，但是哪个会更优呢？最终都能得到同样的结果，那个时候我就得用机器的方式去考虑，怎么样才能最大程度节省资源，提高运算速度。

如果说写脚本的话，高中的时候我已经在干，那个时候是写网站，现在写CSS，然后是 HTML，再到后来当我接触WordPress以后是PHP。一开始用的CSS 那个时候就完全只是控制网站的部分格式而已。CSS可以控制很多东西，但是核心的部件是没办法修改的，有些控制封装在核心部件里，于是自定义CSS无法到达，那个时候我感觉到有一点点的无力。相对而言，WordPress控制方面可以说只有你想不到没有做不到。哪怕有些部分可能CSS真的无能，但实际上当你得知那个控制手段以后，你还可以配合其它的脚本实现某些格式的自定义。

最终让我觉得自己的编程技术总算是用到了点子上是近几年Python，Power Qurey和Power Pivot以及VBA的使用。这几个东西是从Excel的数据处理开始的。我基础的东西都齐全了，但是我怎么才能快捷获取某个成品的结果呢？我知道那个事情该怎么干。但是天天都干，又或者是在很短的时间内要我干那个事情，首先是觉得很烦，其次是非常容易出错，于是这让我想到为什么我不能用编程的手段把它们高度的结合起来。要用什么编程语言？其实一直我都在摸索。用过了一段时间，大家都尝试过了以后，我觉得大部分情况下，无论哪个语言，都能获得类似的结果，但复杂程度不一样，在不同设备上的运行速度不一样，需要的设备基础也不一样。我要用什么编程实现那个结果，我就得考虑这些东西。我是不是经常要用，是不是我一个人用，是不是我还得给别人用。最终我觉得稳定性首先必须保证，最终那个结果也是，必须得以某个我要求的方式输出的，第三点就是看看我的第一感觉是哪个编程软件。

可能某一天，某些软件用不了了，我只能用其它方法去替代，虽然这很麻烦，但是我也相信，我有能力可以做出替代，但我希望不需要有那么一天。

又花了半个下午的时间，把前一天已经做出来的Power Query再进一步优化，但是有些细节还是没想到该如何处理，比如说某些品种的价格会发生变动。五个仓本来是三个不同的价格，但是可能到了某个时点，要把它全部都变成一个均价。该如何表达这种东西呢？理论上，那个时点，无论是用三个单价，还是用一个均价，哪一个乘以数量都应该是一样的东西，但是那个时点应该放在什么地方呢？还有就是，那不属于一个出库或者入库，所以不应该有任何的价值变动。如果是完全相等的，还能说得过去，但是如果分明就是直接从一个价格变成了另外一个呢？所以我不知道之前干这个东西的会计到底是如何实现，因为我无论如何用任何单价和数量都得不到她算出来的某个价格。所以到底她用的是什么样的单价呢？又或者说，之所以我算不出，是因为她把一些之前可能没有减掉的东西，也一并减掉了，又或者是反过来，但我完全没有那个信息，所以我没办法完美地把这个模拟出来。

十几年前当我第一次接触数据统计的时候，那个快要退休的老大妈用的方法是在Excel里做一个很大的二维表。因为仓号很多，日期也很多，她选择的是以日期作为横坐标，仓号为纵坐标，她的那张大表得连续用好多张纸才能完整打印出来，然后用胶水把它们粘起来。也有好一段时间，我也在重复着她干的这个事情，不过我再也没有打印出来。因为我没有打印出来，所以我跟她的思路有点不一样，我把横坐标跟纵坐标调换了一下，因为就拖动鼠标来说，纵向比较容易实现。

又过了好多年，他们又把我从一个全职检验员变成了一个全职统计员，所以我又得跟这些数据打交道，但那个时候，我就再也没干这种事情。我已经不记得什么机缘巧合之下我认识了数据透视表，可以肯定的是不是因为任何一个同事教我，也不是因为学校里面有任何相关的信息，但不知道为什么，我就突然间通窍了。在那以后，二维表这种事情都是数据透视表干，我只需要把一维数据处理就可以了，但实际上身边的人，无论他们一直跟数据打交道，还是只是个初出茅庐的人都一直在不断地填写着二维表，不断努力地把二维表的数据更新到新的二维表里面。这个东西我非常反感，因为就数据处理来说，非常容易出错，比如某个地方理论上应该是一个公式，但你却把它贴成了纯数字，那个地方就算是彻底完蛋了。如果你检查的时候没有发现这个问题，这将成为一个永远的系统错误。这种在二维表上原来是公式的地方贴成了纯数字，又是一个非常容易犯的错误。所以我真的很敬佩制作那个国粮局报表一开始电子版的那个人。他把纯数字的地方跟公式的地方用不同的颜色填充。一开始我不知道不同颜色有什么用，但突然我就不小心发现了，填表变得简单。你千万不能动某个颜色的地方，填数就仅仅在某几行或者某几列。这真的是一个很绝妙的事情，虽然接到那张表的时候，没有任何一个人告诉我原来那个东西是这么用的。现在已经有了国粮局的网页直报系统，在某些行里填数，数字会自动汇总到另外一些你不需要填的行里，需要填写的背景是白色的，不需要填写的背景是绿色的。对老司机来说知道该怎么办，但如果老司机带新手的时候不跟他说，汇总的那些不用填会自动生成，估计新手会觉得要把汇总的部分也填上去了，但实际上可能那些绿色的部分根本不允许填数。现在的国粮局系统是这样，以前的电子版大概也是这个道理。会有些人不明所以，会在那些本来是公式的地方，贴纯数字，于是，本来完全不需要你操心的部分就变成了你全部都得兼顾了。可能从前国粮局的那个报表不是单位的某些人发明的，而是上面下发下来就默认带有那些颜色，但是他们又做得不太彻底，比如有公式的部分没有设定为完全不允许修改。

数据的处理，当你真的用心了，才会有真的感悟，而不只是遵循别人的“规则”。

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

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

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

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

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

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

Excel的一般公式，我比较熟练，一些高级公式的叠加，我需要找教程套用，但起码我知道那是可以做到的。一般的数据透视表，是我一直以来用得相对来说最顺溜的东西，至于高级的数据透视表，也就是超级数据透视表我几乎不了解它的高级用法。在数据的筛选查询方面，之前我用的是公式，而近期，我知道了有Power Query这种神器。在这之前，我已经知道可以SQL语言查询。去年我开始系统学习了Excel VBA。这让我大大提升了某些工作的效率。当然这是非常有针对性的。对我来说，要开发一个VBA脚本需要好些时间，并不是一写就能用的那种类型，期间要经过不少修改。所以其实总的来说，对Excel的了解我还是比较全面的。

也正是因为有这样的经历，所以当我遇到某些综合性的问题的时候，当别人把目光主要集中在某个他们很熟悉的版块的时候，我会凭借我的直觉找问题，而不局限于他们觉得出问题的那个地方。比如在把SQL查询跟VBA结合的时候，别人会把精力放在SQL查询有没有写错上面。SQL有没有写错，其实我根本没看，对我来说那些东西太长了，看不懂，而且那个人写的VBA脚本缩进很有问题，看得我很郁闷，所以我就更加没有心情在那里琢磨。那既然能计算出一个正确答案，说明那个查询语句应该没什么问题。也正是因为写脚本的人的那堆东西格式比较混乱，所以我有理由怀疑那是拼凑起来的脚本，因为居然在脚本的开头连变量的定义都没有。为什么VBA里没有进行规范的变量定义，后面也居然可以照样使用呢？这让我有点惊讶，毕竟这是个VBA，不是python。C语言里，如果不先进性变量定义，后面根本用不了。在我记忆之中，VBA的变量在使用之前是需要先定义的。最终我发现是那个人的脚本之所以出错，是因为某些语句的套用搞错了，为什么他会把那个东西放在里？我觉得大概是因为他没有明白他一开始做的那个with是什么意思。但如果你问我为什么他把那堆东西套在里面会出错，而且是某些地方出错，不是全部出错，我回答不出来。理论上这种错误能在恰当的调试中体现出来，但实际上，VBA的调试句子我还用得不算很熟练。或者你会说，这是因为我的VBA学习还不够系统化，但我觉得我已经用了学习VBA最靠谱的那本书了。可以肯定的是，一些很基础的调试方式我还没掌握，如果我学会了那些东西，我可以大大提升我的调试效率，把错误定位得更精准。VBA脚本这种东西，我觉得最根本的是必须得理解。如果纯粹是各种套用，基础功能的确可以快速实现，但是当遇到的问题比较综合的时候，就会出现一些他们完全料想不到的状况。那种状况有可能与脚本本身的内容无关，与脚本的结构有关。

相对来说，Excel里我用得最弱的是高级公式的套用。如何用一个非常复杂的公式解决一些高端的问题是我一直以来都不大上心，或者说记得不够好的部分。非常复杂的公式，尤其是数组公式，虽然能解决一些神一般的问题，但问题是，其实那些公式需要耗费大量资源，所以在处理大数据的时候，非常有可能出状况。我是一个实用主义者，能做到某个功能，但是做起来的效率不高不好，我为什么要选择那种只是看上去很炫酷的方式呢？情况就像用VBA解决同一问题的时候，如果只是在工作表层面处理和先用内存数组处理再在工作表层面表达，效率千差万别。

Excel对我来说，除了要最终结果，过程也得追求高效和方便。