我的天

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对我来说，除了要最终结果，过程也得追求高效和方便。