我的天

上一篇说到了数据汇总的问题。这个周一我就是按照上周五设定的那个步骤去做。在做的过程中，几乎没有发现什么问题，但是当我做完所有，一个个表格验证的时候却发现不知道为什么有些表格 SQL抓取的数据不完整，VBA从原始表格筛选、抓取的数据没有问题，但关键是SQL从本地的文件里提取到的那些数据不完成。第一次发现这个问题的时候，我看到的是为什么汇总数不一致。当我把SQL回退到第1步的时候发现第1步获取的数据就已经不完整。明明有50行数据，实际上只能提取到42行，重复多次依然是那个效果，但是偶然当我把文件关掉重开以后又好了。所以这个有时发生，有时不发生，到底是什么情况呢？当我打开VBA文件，一个一个测试的时候，发现前几个还好，后面就会出状况，可能是数据不完整，也可能是弹出一些莫名其妙的错误，但只要你把所有Excel都关掉，再重新打开又没有问题了，但是在测试几个以后，又会出现这样这样那样的状况。用VBA+ADO+SQL整理输出数据我已经实施过很多遍，之前从来没有遇到过这种神奇的状况。最后当我打开VBA脚本，无意之间拉到最后，居然发现cnn没有close，也没有初始化。cnn是个非常牛逼的东西，但是那个玩意也要耗费巨大的资源，在我出现数据状况的时候，我没有观察过我电脑的性能到底如何了，会不会CPU或者内存甚至二者都有点状况了。因为一次又一次的验证数据就意味着我得一次又一次调用cnn，光是打开又不关闭，最后就会出现奇奇怪怪的事情。当我把所有脚本都加上了结尾以后。从头到尾10个表以上的数据，一次性搞完，期间不会出现状况，所以多么神经质的行为才会导致了这种弱智事情呢？以前我倒真的从未试过这样。有过这样的经历以后就让我明白到cnn打开和关闭都必须是一个闭环，在一个宏里就得实现到位。如果某个宏被卡住了，半路停在那里，估计那个cnn是不正常的，当我又再次启动其它，只会让错误不断积累，最终导致崩溃，又或者是得不到我想要的东西。

写程序可以很快，但是调试却非常耗时间。这大概是所有码农都必须面对的事情，但实际上更多的人只顾写，只顾实现，而不考虑全盘，不尽可能地用全面数据测试，最终的结果就是使用的时候出现各种各样的未知情况。我不知道其他人到底是如何调试的，反正我真觉得调试的过程比写脚本更费神，因为要考虑所有的情况，哪怕某些条件可能非常极端，几乎不会碰到，但即便那样，一个健壮的程序应该依然能捕捉到那个错误，然后给出对应的反馈。比如我抓取不到数据了，我就应该弹框告诉人家我抓不到，因为有些操作的抓取数据以后才能进行，所以既然能判断抓不到数据，后面的也就不用继续了。

调试程序是一个很磨人的过程，这个过程重复多了，人自然而然就会向完美靠拢，即便我们一定不能成为完美的那个。

上周五基本上我已经完成了，自己第一个VBA+ADO+SQL的跨表查询，接下来我还得在那里逗留多长时间还得有多少bug需要改进说不准，得一边用一边发现问题。做的时候觉得没问题，用着用着就会发现各种问题。比如第一次发现的bug是明明那个ID理论上就只会有一条记录，因为所有和那连接的东西都是左外的，但问题是我这个合并的新手犯了个很无知的错误，在进行左外之前虽然我也已经做了分组，但是除了那唯一的ID以外，我把其它信息也一并分组了，虽然合并的时候指定的是ID，但实际上合并上去的其它性质不一样，即便分组了，合并的数据还是会产生很多行。最后出来的结果就是虽然其它性质的东西并没有体现在最终的合并表上，但是它们却以隐身的方式体现了出来，因为它们的存在，让那唯一的ID出现了好几行。把右边那个表的数累加起来，数据是正确的，但左边的那个ID一样的数据就重复了好几遍，结果只要是左边和右边交互生成的数据全部都乱套了。最终的解决办法很简单，就是在合并之前做最后的分组的时候除了合并的那个关键字以及已经分组聚合的数据，其它东西一律不要存在。

VBA方案中招了，python方案也中招了，但是PP的方案没中招，这在我意料之中，但是PQ的方案居然也没中招，这个是我无法理解的。为什么同样的思路同样的合并方式，PQ就不中招呢？还是说之所以PQ不中招，是因为第一次发现的时候我已经改过来了，只是后来我又忘记了？

周一的早上，当我在上报纸质数据之前做最后核对的时候，又发现了一个bug。汇总数量没有错，但是根据汇总数量生成的百分比不对。拿个计算器按一下就发现不对头，跟其它方式生成的数据相对比也不对头。百分比第二位小数都为0，引起了我的注意。因为正确的结果应该是不都为0。接着我马上想到了自己对其它不是百分比的数据全部都进行了四舍五入到三位小数，但是进度我也四舍五入到了三位小数，但实际上进度是有两位小数的百分数，也就是需要保留的是4位小数。我把最后一位抹掉了，当然出来的结果跟理论上的那个会有差别，而之所以在其他方式没有犯这个错误，是因为其它方式的计算过程中，我没有对进度这个字段进行四舍五入控制。所以解决方法也很简单，我把四舍五入的位数从三位改为四位，又或者是直接取消四舍五入就完了。
VBA是个奇怪的存在，因为实际上它所用的四舍五入并不是经典的四舍五入，而是科学领域常用的四舍六入五成双。我在大一学基础化学的时候第一次听说这个，那时真的让我每次都想半天才算得清这个东西。我毕业以后，去某个单位实习，做完某个检验需要计算结果，那个结果也需要使用四舍六入五成双，每次遇到那种数据我都得慢慢想清楚。VBA这个四舍六入五成双跟一般的Excel算出来的四舍五入效果不一样。这就会导致用脚本生成的数据可能会跟人肉算出来的有差别。程序员们只能用自己的方式重新把一般四舍五入的效果模拟出来，不得不放弃VBA原生就有的四舍五入函数round。我运气好，还没遇到这种问题，而之所以没有这种问题，是因为除了进行乘除法以外，加减法的时候，我是不会遇到小数点三位以上的数据的，所以起码能保证通过加减法出来的东西都不会有这种问题导致的误差。至于乘除法出来的数据，实际上我也只是看一下而已，比如那个进度，上报的进度数据我会在手工纸质的表上用一般的Excel公式生成。

越研究就会越觉得自己无知，那些实际过程中积累的经验比直接从别人那里一二三四学回来的深刻多了。

昨天晚上，在做那些文字游戏的时候，我做到了好像怎么费劲就轻而易举地把题目做出来了，只需要几分钟到十几分钟。从写脚本到测试成功，整个过程没有状况，甚至写完脚本后，所有东西下面红色波浪线都没有。通常，我都会习惯忘记在句子的结束加上冒号。Python要求必须严格缩进，多了少了都不行，而且使用缩进必须用一样的方式，通常必须要求用4个空格。习惯了用VSCode以后，我会设置缩进为4个空格，当我在上一行回车之后，如果上面是冒号，下一行就会自动缩进4个空格。但如果某段代码不是我写的，而是从某个地方复制过来的，就可能会出现状况。所以为了避免这种无聊的出错，我把所有占位符都显示出来。比如空格，也比如tab。大概对其他人来说，写代码就应该是行云流水的。知道自己要实现的功能是什么，知道自己应该用什么方法，然后按照思路按部就班。调试这种东西没有个尽头，没有说用了某些方法测试就能一定保证调试完以后程序没有任何的bug。只能做到尽可能少bug，不可能做到完全没有bug。不知道从什么时候开始，我觉得不把话说死非常重要。

昨天我终于体验到云流水般写代码，是因为在行云流水之前我已经纠结过好几个小时。在行云流水之后，我也遇到了命令行的光标卡在那里，不显示程序有错误，但是程序也不进行下去。如果我进入了死循环，程序出不来，Python会提示我上面已经进行了超过994行，别浪浪费大家精力了。之前我已经见识过了。而昨晚我遇到的是光标停在那里，没有任何提示。脚本那里也没有任何红色波浪线，说明语法是对的，起码静态语法没问题。当我再次看到脚本的时候，发现原来是我在用while进行循环迭代的时候，没有设置改变条件的东西，于是while的循环就停在那里了。在我构想那个循环的时候，其实我是设定好增量条件的。我的脑子已经准备好了，但我的手指并没有把增量条件敲上去，所以就出现了之前死在了终端的状况。我不知道光标死在了终端我还能做些什么，反正我的处理方式是把终端关了。光标停在那里，输入什么都没有反应，又或许如果我在单独的CMD命令行里搞那个的话，我可以用某些什么方式从那里跳出来。只是我现在不知道该做些什么。因为我是在VScode的测试，所以我简单地把那个终端的窗口关掉，重开一个就好。

还记得，在大学里学习C语言的时候，其实我不怎么喜欢用while这个东西循环，我更喜欢用for。拿Python跟C语言比，我觉得后者需要我们在写代码的时候更加仔细严谨。比如花括号这种东西绝对不能省。也比如某个对象在使用之前必须先声明，不只要说明它存在，而且要确定好那是一个什么类型的东西。在循环控制方面，C语言一开始就必须得想好所有。相对而言，Python很自由。昨天我突然发现原来in这个东西可以让if这种语句也具备循环的功能。在实现某个功能的时候，我用了两个for嵌套，而参考答案只用了一个for和一个if，出来的结果完全是一样的。我在两个for里还得加个if做判断，相对参考答案而言，显然就有点臃肿了。

我明明知道做习题会让我死去活来，但是一定程度上，我却在享受那种征服未知的刺激。