我的天

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

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

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

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

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

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

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

python的习题我已经习惯了他们不给参考答案，又或者是参考答案里有一些超纲的东西。既然这样，如果我可以用我学过的东西得出答案，我会努力地那么干，但如果我实在没办法，就会请教搜索引擎，然后我也会用上一些超纲的函数解决问题。现在我只学到了一些很入门的东西，所以实际上现在很困扰我的问题实际上已经有现成的函数可以秒杀掉。秒杀是很简单的，你知道使用范围，然后把东西丢进去就可以了，但如果全部都这样拼凑，跟直接在Excel的系统函数里玩有什么区别呢。知其然，也要知其所以然。经常让我纠结的东西我会想到一些很特殊的情况，我该怎么把那些特殊情况也处理掉呢？当然我想到的特殊情况可能并不算太特殊，又或者还有很多特殊的东西我没有考虑到。内置的函数里，很多东西都固定了取值范围。比如说针对字符串的函数很多东西，你只能在里面填字符或字符串，你不能把列表、元组或者字典丢进去，所以这就很烦恼了，如果我要处理的不只是我能列举的那些字符呢？比如说我要处理的是32个半角的标点符号，我要把他们替换掉，它们32个是以一个字符串的形式放在一个函数里的，你可以直接的把它们引用出来，但是，如果你要把它们替换掉呢？我遇到的问题是，我需要把它们全部删掉。为了实现这个，我写了个循环，历遍了字符串里面的32个元素。然后把它们逐一替换为空字符串。后来我认识了一个比较高大上的函数，叫translate，而在translate之前，又有一个制定翻译规则的函数maketrans。Python3中，maketrans已经被列为内置函数，不需要再引入模块才能使用。Python3的maketrans有一个相当牛逼的功能，就是在创造翻译规则的时候，我可以引入字典。这是一个非常妙的点子！因为在创造翻译词对的时候，强制规定前者跟后者，必须是等长的，而字典的键与键值一定会成对出现。一开始我用那个函数的时候，被翻译的是32个字符，然后我手动数了32个空格进去。后来我为这32个字符建立了一个字典，然后优雅的把字典丢给了maketrans，最终让translate秒杀完事。

关于分隔出一段话里的每个单词这种事，正常人的思路是筛选出那些0-9以及大小写字母。但是，在一开始的时候，我被暗示要用减法。首先，把整段话都变成小写，然后剔除掉里面的标点符号。最终根据分隔符把单词切开。如果一开始，我就想到用限定字符的话，我会从正则方面考虑，但貌似我的做法跟正则出来的效果有点不一样。因为正则之下，居然星号、逗号和杠都没有去掉。这让我非常惊讶。当我对比我的方法提取出来的词和用正则方法提取出来的词以后，我发现在那个排版有点过分的emma文件里，我的提取效果要比网友的正则好。虽然总的来说两种方法算出来的单词量没插多少个，但实际上但把差异打印出来以后，效果还是差得挺远的。

我还是比较习惯自己先琢磨一下，得出自己的方法，然后再去跟别人比较。

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

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

用两天才终于搞懂一道编程题目，这实在是太过分了。如果有人指点的话，肯定不需要这么长时间。如果在我看到这道题的参考答案之前已经完全明白参考答案里面写的所有东西的语法，我也不需要费这么多时间。对我来说，这个理解的过程就像是在猜谜语。什么样的东西是True，什么东西是False。理论上，这非常的简单，但实际上，当真的问起你的时候，如果还没有人跟你说过有这样的规则，你肯定想不明白，对我这种人来说，搞不明白就直接把那丢给python，要他试给我看会是什么的状况。

以前做条件判断，我都是用一些很明白的东西。用一些大家都知道是True还是False的东西，比如说条件是1大于2，这显然是不成立的，肯定是False，不会在这个条件下进行。但如果条件判断的时候，我传进去的是一个列表呢？列表到底是True，还是False？有东西，比如数字、字符的列表是什么？如果里面只有一对单引号，也就是空字符，那又是什么？还有另外一个情况，列表就只是一对方括号，一个空列表，这又是什么？通常来说，我不会给自己制造这些模棱两可的烦恼，如果是我自己写的条件，我不会这么折磨我自己，大概我会加个明确的判定下去。万一我真的把列表传进去作为条件判断。我会问那个列表是不是空列表，那个列表的长度是不是大于0？只要列表里面的东西，列表的长度就肯定大于0，无论里面是数字、字符，又或者是其他列表，甚至有元组，哪怕列表里面只有一对单引号，空字符串，其实也是有长度的，这样的列表长度为1。但空列表，就只有一对中括号的东西，长度会是0。如果在一对中括号里面又有一堆小号呢？从外面看来，中括号是有元素的，但是从里面的小括号元组看来，元组。这些说起来挺尴尬的事，如果你不知道他们的规则。无论如何都是回答不上来，答案是什么呢？这些答案又非常的明白，非黑则白，没有其他选择。

我不知道为什么在同一个判断上面，参考答案用了好几个表达式，是写脚本的人故意在用这种方式考验我们，还是说他有点随心所欲呢？对优秀程序员来说，通常不会犯这样的错误，或者说这能算是错误，应该是有这样不一致的习惯。养成一致的习惯是非常重要的，比如说注释的习惯。也比如缩进的习惯，在python里，缩进就是4个空格，没有说尽基本上程序就进行不下去了，因为通常你都要写个判断循环函数之类的吧。对我来说，我还没有养成空格的习惯，比如说，有些时候我的运算符和对象之间有没有空格，但有时却又。我完全是凭感觉。有些时候我会把那些东西搞得很开，有些时候我会挤在一起。当然，通常这些都不成问题。

在一道编程题上我之所以耗费那么多时间，就正如我上面所说，是因为在一些我应该知道的东西上面实际上我不知道。于是我得出一个结论，在看这个Think Python 2的时候，估计我得拿着本python的手册，一边学一边翻。显然Think Python 2这本书不会把所有规则都告诉你，因为他们想让你自己去学习，掌握那些他们觉得你铁定要知道的东西。

我不觉得用两天时间去研究透一道题是在浪费时间。