最近对Excel中的VBA比较关注，一方面是因为公司有几项工作是用VBA完成的，不仅效率很高，而且业务人员的反响也特别好；另外也开始关注ExcelHome网站的内容，还下载了一些大家都评价不错的Excel小工具来研究一下
在做这两方面事情的过程中，我发现，对于程序员和VBA之间，有两种奇怪的现象，和大家分享一下。
首先一点，很多人认为VBA的程序不是真正的程序。
在大多数人的心目中，程序应该是什么样子的呢？要么是Application的样子，或者说是Winfom 的形式，要么就是网站的形式。也就是说要么C/S，要么B/S，而Excel中的VBA程序，应该算哪一种呢？似乎哪一种都不算，因此就可以得出结论，这样的程序不是程序。
在完成工作的时候，自己倒是没有想到这个问题，但是，在做完了之后，部门的主管告诉我说，先这样给业务部门用着，等有时间的时候再做个真正好用的。
其实，我觉得，是否是所谓的程序并不重要，重要的应该在于它是否满足了业务的需要，并且具有很多所谓的真正的程序无法达到的优点。
我开发的抽奖的工具完全符合业务的需要，而且最近的抽奖就是利用那个小工具完成的。它不仅完成了所需要的功能，还免除了业务人员导入、导出Excel数据的工作，而且产生的数据也可以非常方便地利用Excel特有的功能进行各种筛选、排序等等操作。此外，对于业务人员来说，学习曲线极低，我仅仅讲解了5分钟左右，业务人员都可以完全地进行独立操作了。那么，在这种情况下，真的就一定需要开发出Winform形式的东西才能够算是程序吗？
可能之所以有些人更愿意编写Winform或者是Web形式的程序，一方面是因为一直在那样的环境中编写程序，对其比较熟悉，而对于VBA的环境不是很熟悉，觉得会降低工作的效率；另一方面可能是觉得，Excel这个东西，很多不是程序员的人也都能够操作，是办公软件，用这样的东西做，就显不出自己的高明之处了，哈哈。
其次一点，在看了很多VBA程序之后，发现程序中存在很多需要改进的问题。
非常重要的一点在于代码的规范问题，在很多非常有名的Excel工具中，也存在着严重的代码规范问题。比方说各种命名：对于变量的命名还算不错，而对于各种控件的命名，很多人都是采用了原有的默认名称，像CommandButton1、Sheet1；再比方说对行列的操作，存在着大量的“魔法数”，例如对列“B”的操作，就是用“B”，其实对于这样的东西，使用常量定义，可以很大程度上方便开发，而且还会提高程序的可维护性。
这个问题的原因可能在于目前大型的开发中很少会使用VBA作为开发的语言，而代码规范这个东西更多的是存在于大型的项目开发过程中。因此，很多的VBA开发者并没有注意到这些问题，因为没有人去要求。
上面的这两个怪现状是一个恶性的循环，由于VBA程序中存在很多的问题，做过大型项目的程序员就会对只会编写存在大量问题的VBA开发者嗤之以鼻，认为他们不配做真正的程序员，从而更加不会在实际的工作中使用VBA来作为开发的工具。而大量的人认为VBA开发者不是真正的程序员，开发VBA的程序并不意味着具有非凡的技术实力，从而使得更多的人在选择的时候不会以VBA作为开发的工具。
针对上面的情况，我有两个建议：一是大家要认清VBA的好处，在某些特定的情况下，它可以大大提高开发者和业务人员的工作效率；而是作为VBA的开发者，应该注意培养一下自己在代码开发过程之中的一些素质，比方说代码规范，比方说DRY原则等等。
欢迎大家对此进行讨论！
喜欢 
顶
难过
囧
围观
无聊
