PL/SQL代码分析工具之创建高水平的设计

　　您已经看到了我的参数信息源的复杂性。我需要能够干净利索地提取、合并，然后从原始数据中得出结论。这可能将涉及到相当多的后处理。

　　报告分析结果也可能将是一件繁琐的事情：如何避免 DBMS_OUTPUT 的缺陷？如何设计输出的外观？

　　我无疑将需要一些小型实用程序，以便不同的存储桶共享它们。例如，考虑到它所有的值这一麻烦，我费力地避免了对 DBMS_OUTPUT.PUT_LINE 的直接调用。

　　随着我越来越深入到 ALL_ARGUMENTS 和 DBMS_DESCRIBE 中，并试图处理更有挑战性的分析类型时，事情变得越来越复杂。如果我试图愚弄自己，认为这很简单，一晚上就可以搞定，那我将注定要失败。我可能不想预先详细考虑每一个可能的问题，但我也想为变化作好准备。

　　哦，别忘了测试的问题。我将需要一个与 utPLSQL 兼容的程序包来包含我的单元测试过程。

　　在思考了所有这些以及更多的问题之后，我发现我逐渐接近了图 2 中所示的功能存储桶。仅仅识别象这样的不同区域并不够。我还需要尽可能清楚地预先确定每一个存储桶的用途、存储桶包含什么、您能在里面放入什么、以及能取出什么。处理它的另一种方式是，我需要为每一个存储桶定义握手方式 — 程序与存储桶通信的方式，以及存储桶反过来与调用程序通信的方式。

　　如果我很使得存储桶之间的区别明显，那么在任意指定的区域中添加功能，以及将来修补程序都将更容易。这些存储桶之间的牵连或相互依赖性会达到最小。将新的函数或过程放在什么地方将会很清楚，因此，在哪里能找到它也会很明确（这是最重要的，否则如何使用它？）。

图 2. Codecheck 功能存储桶

　　当我象这样分隔代码时，还不可避免地要对程序包的层次结构进行考虑。在这个层次结构的最顶层是最复杂的程序包或程序，它们构建于其它许多元素之上。在最底层的是不可分割的程序包 — 小型、高度集中的程序包，它们支持一种用途，并且与其它的程序包没有太多的相关性。