PL/SQL构建代码分析工具之从测试开始

　　在本系列的第一篇文章中，我决定构建一个可以对代码进行质量检查的实用工具：特别是识别 PL/SQL 程序包中具有歧义或者潜在歧义的超载问题。

　　此外，我还识别数据源（ALL_ARGUMENTS 数据字典视图）和代码（DBMS_DESCRIBE 程序包），以帮助构建实用工具。下一步要做什么呢？

　　坦率地说，我自然倾向于打开我所喜爱的集成开发环境 （IDE） 并开始动指如飞地编写代码，投入激动人心的创作之中。我希望在工作时思考并得出结论，不断地应对挑战，使工作成果运行起来，然后对其进行微调。

　　这种方法有积极的方面（您当然不会有过度设计的风险），但也有很多缺点。首先，如果我所使用的构建方法是直通式构造非线性系统 — 常被亲切地称为 HRCLS 或 Hercules（一种非常轻型的方法论），我最终不会仅是微调代码。绝对不会，在我将范围缩小到最终目的、目标和实质内容时，我最终将会以重写整个程序一次、两次或三次。但是，尽管可以激动地看到，经过自己的努力，实用工具成形、进步并改观，但这会浪费很多的时间。

　　对于 Codecheck，我会忍住最初的诱惑。我不会在项目开始的头 60 秒内就编写代码，而是做一个简单的声明：我保证使我编写的代码适用于一个全面的测试计划。

　　这与避免 Hercules 综合症有什么必然的关系呢？让我们来考虑这种保证的含义：

　　我将制订一个测试计划，它非常全面，精心策划了数十个（甚至可能有 100 个之多）测试方案，包括参数的数量、各种数据类型的结合以及缺省值的有无。

　　我要设计、构建和运行测试，这些测试可确定我的代码是否满足测试计划的要求：换言之，设计、构建和运行涵盖我的全部测试方案的测试。

　　天哪，这听起来确实很有道理，不是吗？我的意思是，谁会一直做所有的这些事情？况且，我们都知道这样的事实：我们之中很少有人实际上会花时间，或在手边有必备的工具去做全面的测试。实际上我认为，世界上至少百分之九十的软件开发人员和开发团队（包括我自己）远远不会完全按上述保证去做。