我的天

要实现某个功能，有非常多的做法，到底要怎么做才能避免出错呢？Excel的函数非常牛逼，把那些公式弄好了，简直就是天下无敌的节奏。公司的原理很简单，但是套用起来做着做着就傻瓜了。有可能是手贱，标点符号按错了，更大的可能性是单元格引用出错。我已经不记得用Office 2003的时候是个什么状态了。反正在Office 365下面，如果在一个工作簿里面应用了别的工作表，把带公式的工作表复制到另外一个工作簿里的时候，那些引用的单元格会以绝对地址的形式继续指向原来工作簿的某个表。显然，如果只是指向本工作簿的话，找不到地址，顶多显示错误，但是如果那东西继续指向原表，会引发很多问题。因为那是一个绝对地址，即便你把工作放在同一个文件夹下面，还是不能解决问题。恐怖的绝对地址会导致云同步、在多人协作的时候，发生状况。为什么Office 2003下就没有绝对地址和相对地址这个烦恼呢？在Office 365下，数据透视表的绝对地址算是终于改正过来了，但我想不到公式居然也这样。这是一个令人非常崩溃的事情！如果工作表里面的公式是大量的，这将是一个灭门灾难。如果某一个工作表里面的公式是大量的，而另外一个工作表里面的源数据也是大量的，外加还有一个数据透视表指向了源数据。无论是动哪一个，都会导致另外的那个上的工作推倒重来。为什么就不能设置某个工作簿里面的链接采用相对工作簿内的连接，而不使用外联呢？停止了外联，就意味着那个单元格的数据从一个动态的东西变成了静态的。绝对地址这个问题，在云同步、在多设备协作的情况之下，根本是无法操作的，为什么微软会犯如此低级的错误呢？数据透视表的傻逼是发生在Office 2010版之后的。公式上的傻逼，之前貌似我还没遇到过。可能并不是因为不存在，而纯粹是因为我没有用到这种功能。

但Excel不能一次性满足我所有想要的东西的时候，我就会想到要不要自己写个脚本解决一切难题。人想得到的逻辑，用脚本都能实现，前提是必须考虑出一种能够包容所有例外的规则。如果不能包含特殊情况，脚本写出来是毫无意义的，因为最终还是得人手去加工，这非常不科学。所以一定程度上，我更喜欢用数据透视表，自动处理那些东西，而不是手动设置公式。设置公式理论上是一个一劳永逸的过程，但实际上只要你手动在上面修改了一些东西以后，就像蝴蝶效应一样，后果不堪设想。某一次的修改，会导致往后半天都找不出原因。如果用数据透视表的话，双击单元格就会到达最基础的那个数据。查错是非常简单的，但是，用了公式以后，然后你又因为某次犯傻在某个你以为设置了公式的单元格里面输入了常数，那将导致一次令人绝望的debug。不要问我为什么会知道……

与其让我查找错误，还不如让我总结特点制定规则，让他们不犯错误。当然，不犯错误，是根本不可能的。

很多人听到审计的要去查，就会非常紧张。审计到底有多厉害？如果我对自己的业务非常自信，我会怕吗？的确我没什么好怕的，但是我的队友不知道自己要怕。昨天我见识到了一份审计发过来的罪证单。当然这不是直接发给我的，是发给我领导的，但要我去研究该怎么答复上面提到的问题。接到那个文件的时候，我震惊了。因为那是一个宏的Excel。这样的保存方式，就意味着里面一定有一些牛逼的东西。我自己也是一个写脚本的人，我当然知道其中暗藏武功秘籍。那个文件看上去数据不多，但是却非常大，这让我挺震惊。后来我发现可能是我想多了，因为之所以大，是因为里面贴了几个图片，所以很大，并不是因为里面的数量非常恐怖。

拿到那个文件的时候，我不是对数据感兴趣，而是对里面的脚本感兴趣。到底他们写了什么脚本，可以在那么短时间之内汇总校对出我们的数据，然后发现问题呢？后来我发现，其实，他们没有在里面写脚本，我一页一页地翻查过了，但是他们用了宏函数。他们把那些东西隐藏起来，比如说把带公式的工作表隐藏起来。隐藏工作表很好破解。起码他们没有用带密码的方法到锁定工作表，完全不让我把隐藏了的东西取消隐藏。让我觉得有点惊讶的是，他们居然就这么坦荡荡地把他们的研究结果发过来了。他们就不怕我们偷师吗？正常人见到这样的文件早就已经瑟瑟发抖得无以言表了。其实我更想知道他们在得出最终的这份问题清单之前是怎么快速的处理我们的数据的。在数据的汇总以及财务业务处理方面，他们实在是精英，不只是这样，他们对所有东西都非常好奇。他们简单来说有学者的脑袋再加几岁小孩十万个为什么的心。一定程度上，我应该害怕这些人，但是实际上，我却挺喜欢他们的工作风格。他们做的事情跟警察探案没什么区别。他们把一些我们这里的人害怕去面对、囫囵吞枣应付的事情非常有条理地罗列出来，得出结论，并告诉你你犯了那个天条。那种细致和博学简直是到达了一种让我莫名崇拜的地步。

崇拜归崇拜，最终我的领导把那个文件发给我就是要解决上面的数字问题。让我兴奋的是，我居然发现有一些我们的数据跟他们的数据有很大差别的地方原来是他们的公式写错了。明明是应该乘0.6的地方，他们用了除。我不知道他们为什么会犯这种错误，是手误吗？因为其他工作表的同一个公式没有问题，唯独其中两个出差错了。也正是因为那个问题的存在，所以我们的总数在那一块跟他们相差了好几万块钱。在阶梯式计费方面，我觉得他们的公式已经用得很好了，但是即便你厉害到天上去，还是难免会发生某些疏忽。于是，这就启发了我要去研究到底用什么样的计算方式才能减少这种问题的发生，甚至是杜绝这种问题再次出现。

在遇到审计之后，我有种相逢恨晚的感觉。

大概2020-04-22就听说Office 365要变成Microsoft 365，但我Win 7上的Office 365貌似没有什么变化。之前更新了个版本，牛逼的filter函数有了！有了filter以后高级筛选那些复杂的东西根本无需存在。如果只是为了筛选明细，filter很完美了。我觉得这个应该是数据库的函数，但现在也直接在公式层面实现了，牛逼！filter能做高级筛选，但如果我要的是筛选后数据的汇总，我个人感觉还是数据透视表好一点。其实数据透视表也能做明细的筛选，但要实现那个，之前你得先给明细数据增加一个唯一的序列号。从接触Excel开始我就认识高级筛选，但显然除了是老师要求必须得那么干，我平时是不会用到的。我会对多个条件进行筛选，但那都只是单条件筛选的叠加，这个做法在实际工作中更常用。有了filter函数后，筛选又可以玩出新花样了，实在让人很兴奋。不过兴奋归兴奋，filter是Offcie 365的新函数，Office 2019有没有都是个问题，反正Offcie 2016是无论如何都没有的了。之前我还担心了半天Win 7下的Offcie 365会不会给我增加，因为自从微软停止支持Win 7以后，Win 7上的Offcie 365只会进行安全更新。如果是系统性能不支持，新功能更新不上去也就算了，但如果系统是支持的，只是因为微软要强迫你放弃Win 7，放弃老电脑，必须得买他们的新硬件、新软件，这样就太霸道了不是吗！filter这个函数能在Win 7的Offcie 365上使用，一定程度上我觉得是运气。我能使用，但如果我把文件发给别人，他们没有这个高级别的Offcie，还是会撞板。从前我觉得Offcie版本的不同对我来说绝大多数时候都只是版式上的改变，其实功能还是大都不变，所以我才会一直使用Offce 2003直到Offcie 365（当时对应的是Offcie 2016）。之前我之所以没有欲求，是因为新版本Offcie有什么我不知道，我不知道都增加了什么，怎么会对那些内容感兴趣呢？！

人知道得多了，就会有种冲动想知道得更多。这种与生俱来的冲动我都说不上到底算不算是递归。

过去的4月，已经有3拨审计的过来（前3拨，只完成了1拨），明天还会有第4拨。我不紧张，顶多是把纸质材料从已经归档的盒子里拿出来，排一下序，电子版也从已归档的地方拷贝出来整理一下。该干的我从前都已经做完了，没有可慌的。我的同事也不觉得他们有什么可慌，但检查过程中，他们的流程漏洞百出，为什么他们应该做的事都没做？为什么这般整居然没人知道？没人觉得不妥？没人要求他们必须改？懒惰得有个限度，当懒惰到达连最基本的逻辑都无法保证，这就太说不过去了！

我一直在严防死守，但原来别人不是……

我前天开始系统地学习R语言，用的是一本叫做《R语言统计入门（第二版）》的书。那本书从最最基础的东西开始说起，基本可以说是零基础也能学会。我去说，书里面的内容是统计学和工科大一学生应该掌握的基本概念。现在我只看了一点点，感觉挺有趣，有些东西很容易理解，但有些东西却要绕一个弯。其实之所以这样，是因为R语言设置了很多潜规则。跟我之前学过的C语言不一样，R语言的潜规则多得多，也正是因为，它固有的规则多，所以有些东西毫不费劲就可以得出一个高端的结果。比如，当你要算一个数组的平均值，又或者是标准差的时候，一个简单到爆的函数就搞定了。如果要手工实现那个函数，真的很费神。我觉得R语言这个东西，只要你领会到规则的制定方法，很多东西都可以融会贯通。重点就是你能不能领会到那个精神，消化他们的东西成为自己的一部分。Excel的VBA里面也有很多潜规则，但是，跟R语言比起来，Excel里的很多东西貌似就有点复杂麻烦了，比如说，连起个名字，Excel里面的东西都要比R语言长。

我觉得对我来说，学习R语言跟学习Excel VBA，虽然都是编程语言，但二者不一样。VBA更侧重于技术实现的层面，要解决一些具体的东西，之所以要写VBA，不是要做研究，而是要得出某些结果，通过简单的操作就可以把复杂的流程秒杀搞定。其中的逻辑在写VBA程序的时候就必须已经想得很透彻。又或者可以这么说，在写VBA的时候，实际上你已经通过其它方式，得出了一个你要得到的结论。虽然你不可能所有数据都已经得有结论，但起码在某些数据上面，你已经确信那就是你想要的结果。大概因为我对R语言还了解得不够透彻，所以我觉得R语言最看重的不是结果本身，你不是为了要验证某个结果而去用R语言，而是要让R语言帮助你找到某些东西的规律。

之所以认会到R语言，是因为它有强大的绘图功能，几乎可以这么说，只有你想不到，没有它做不到的。R语言做出来的那些图，跟艺术家很写意地画出来的不一样，R语言做出来的图都是根据某些数据按照某些规则合并计算而来。有些数据摆在一起，我们不运行软件，也能预测到那估计是一个什么样的趋势。在一开始的时候，我们必须了解这个趋势，当R语言把图做出来的时候，我们才可以判定我们的方法有没有用错。当R语言我们已经用得很熟练的时候，我们可以要把我们的数据放到R语言里，然后通过某些我们已经应用成熟的方法让软件给我们得出图像，接着我们再从图像里得出某些结论。

不知道从什么时候开始，我迷上了数据可视化。把一堆数据用表格体现出来，和用图像表达出来效果很不一样。如果图做得好的话，那会给人一种惊艳的效果。如果你只看到一堆表，你的大脑还得寻找表格里数据的相关性，然后在脑子里想象出它们应有的关系。在靠谱的图里面，数据关系直截了当很明白，无论你是老手还是小朋友，在看图的时候，你都能很直观地感受到。

有时我会想，为什么现在理工科的学生仍然要学习C语言，而不直接学习R语言呢？尤其是那些非计算机专业的。理工科学生的课程里必然会遇到带入各种实验和数据分析。不过呢，大学的课程连Excel都不会很细致地讲明白，他们又怎么会把R语言放在眼里呢。

编程语言是种必需掌握的技能，谁是你的菜就得看这个社会推动的是哪种，又或者是你打算用在哪个领域了。

有一句类似这样的话“数据汇总时流的汗就是数据录入时脑子里进的水”。跟别人对数这种事，通常来说都不会太顺利，反而我喜欢跟系统对数。因为系统都是按照一定的逻辑整出来的，而我也有我的逻辑，两个东西碰撞，很容易找出差异。但跟人对数就很不一样，尤其是跟不同的人对数，那就更加麻烦，不同的人有不同的手法。不同的汇总方法最终会让你无比纠结，有些数据没有算进去，有些数据直接漏掉了，还有些数据完全是手误。没有算进去的那些可能是故意为之，漏掉的那些有可能是一顿懒惰之后完全不知道还得有那个操作，还有那些手误简直就是一个未知的谜，你根本说不清到底会以什么形式出现。有可能多打一个数字，也有可能是数字颠倒，当你找出那个手误输入以后，你会马上明白到那是怎么一回事，但是要找出那个东西，又谈何容易。

为了保证我汇总的数据不会发生这些问题，所以除了明细数据我需要每天纠结以外，整体的数据我也必须每天核对。有些数据是没办法每天核对的，即便你每天都做明细。因为有些东西必须合并起来才有真正的意义，比如要算清楚每条船的数量，而那条船又卸了好多天。如何解决问这个问题，从前我也死过不少脑细胞。后来我创出了某个方法，但是还是会有点麻烦，最后我只能得出明细的数据做给一个表，汇总的数据做另外一个，然后定期核对，这样能稍微解决问题，而这一招是我昨天和别人核对过数据以后才最终决定的。

我不明白他们为什么要以那种方式汇总。做一个明细表格，掉头还加一行完全无所谓的标题，我个人觉得那是毫无意义的，毕竟那个表不是某个报表，需要打印出来。其次，单元格的合并也是多余。第三，入库跟出库分作两列，看上去没什么问题，但是如果我要一个汇总数呢？明明在其他类别里面已经说明白了，那是出的还是入的，是车的还是船的，也就没必要把数据分作多列，毕竟这不是要算一个库存数。只有出入库数量而没有初始库存以及损溢倒仓转入转出之类的东西，根本没办法算库存。数据分作两列，要做数据透视表还得费劲2合为1。高端一点的做法或许是将二维变成一维，低端一点的做法是直接加一列，把那两列的数据加起来，因为按照那个设计表格的人的思路。入库和出库的数据只填其中一格，所以只要加和两个单元格，最终得到的就是出库或者入库的数据。再来一个万能的数据透视表，需要汇总的数据就能轻易地分类开来。有一定的规律以后，自然可以和其它数据透视表汇总出来的数据做核对。但即便我这么干了，还是很难分得清某些特殊情况。比如某一条船来了很多次，每一次又花了好多天才完成。有些时候是一周来一次，但有些时候一周来两次。当你很久都不汇总一次数据，你怎么知道今天这条船的数据跟后天的要不要加和在一起呢？如果你每天都干，你肯定会知道这是一条船，只是中间有一天天气不好不能作业，但是今天和后天的数据加起来才是一轮操作。这种东西理论上逻辑很简单，但显然，我们那些破系统没有考虑到这种情况，所以得人肉关照。

软件是人设计出来的，但如果人没想到该用什么逻辑去处理的话，软件不可能超越人，让使用者觉得得心应手。