我的天

很多人听到审计的要去查，就会非常紧张。审计到底有多厉害？如果我对自己的业务非常自信，我会怕吗？的确我没什么好怕的，但是我的队友不知道自己要怕。昨天我见识到了一份审计发过来的罪证单。当然这不是直接发给我的，是发给我领导的，但要我去研究该怎么答复上面提到的问题。接到那个文件的时候，我震惊了。因为那是一个宏的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这本书不会把所有规则都告诉你，因为他们想让你自己去学习，掌握那些他们觉得你铁定要知道的东西。

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

循环和递归，对路人甲来说那是差不多的玩意，反正就是在那里转圈圈。但是，虽然已经认识递归好些时间了，但我依然非常害怕这个存在。之所以害怕递归，是因为我很难想象到底递归什么时候才是个头，而我又非常明白，达不到递归的头，就不能把东西返回出来，得到我想要的答案。这个玩意就像一个无底洞。于是每次当我遇到递归，我都会在那里瑟瑟发抖，大概要克服这个，我需要非常大量的递归练习，让理解这个东西变成我的条件反射。

我不知道，在实际编程过程之中，到底会不会真的经常用到递归这种恐怖的东西。在Think Python 2这本书里面，很早就已经在说递归。还记得递归这种东西他们是结合小海龟一起折腾人的。现在回想起来，这或许是个正确的选择。因为小海龟是一个画图的东西，会让你用更直观地去理解递归到底在做什么。我还记得他们要我们理解的那个树杈和雪花。树杈那个图还算是一个比较正经的东西，雪花那个图案，简直是让我头皮发毛。每次说起递归，我就会想起小时候家里那个卷纸筒。黄色的卷纸筒上面，有一个卡通熊猫在拉卷纸的图案，而它拉的那个卷纸筒上面也贴着一个熊猫在拉卷纸。每次看到纸筒上的那个图案，我就会盯着看，然后脑子就会不断想象，熊猫卷纸筒，熊猫卷纸筒……想着想着甚至会觉得好恐怖，到底什么时候才是个头！这跟俄罗斯的套娃不一样。我总觉得，俄罗斯套娃无论套子多精细，总会有个头，但是，拉卷纸的熊猫，对我来说简直是个噩梦。我觉得，拉卷纸的熊猫是递归，而套娃是循环。

昨天我花了大半天的时间查单位的某些账本。查出了一箩筐的问题，我不知道为什么之前他们检查居然没发现。绝大多数都是弱智的问题，不弱智的问题则代表了他们做事的时候根本没用脑子去思考。那些莫名其妙的错误几乎到达了一种人人都有永不落空的境地。这也实在是太强大了吧！归根到底，是因为根本没有人去统一他们。每个人都看着那个规则，每个人都有自己的理解，又或者他们没看规则，只是按照上一个人的方法去做，但是他们对上一个人的做法的理解又各不相同。情况就像一个人不断地传话给下一个人，当人数传到一定程度的时候，原本的故事就会变得乱七八糟。我还记得第一次发现这个现象是在翡翠台的综艺节目超级掌门人上。这是我第一次认真地去揪他们的错误。不只是核对核心数据，也看了格式上到底合不合要求。有时我真的不明白他们，这样干活，他们觉得自己对得住自己的工资吗？他们晚上为什么居然能睡得着觉？换个说法，为什么他们这般吊儿郎当却没有东西惩罚他们？即便不是金钱上的惩罚，但起码也要让他们心里不好过，比如批评一下。但或许批评根本无效，就像你妈妈骂你一样，左耳进右耳出，就只是一阵耳边风。既然不能用惩罚，能不能用奖励的机制呢？在这个单位，爬上去的那些人你也说不上到底牛逼在哪里。没有惩罚，也没有奖励，于是也就可以理解，为什么他们会这样。

不是人人都能自律，对不自律的人必须用铁手腕。