Steven Feuerstein ：PL/SQL是和非

admin

   PL/SQL是Oracle的程序设计语言，用于存储过程，它为你的数据库程序增加了许多可能的功能。PL/SQL补充了标准的关系数据库语言SQL，提供了各种过程化特性，包括循环、IF-THEN语句、高级数据结构以及丰富的事务控制，这些都紧密地集成到Oracle数据库服务器中。

　　程序员请求帮助是合适的吗?

　　绝对不是!如果你请求别人的帮助，那么你正在表现你的差劲。很多优秀的程序员将会孤立你，因此“最近的捕食者将会吃掉你而不是他们”。

　　当然，程序员不是鸟儿。我们不需要担心捕食者，我们要担心的只是写出满足用户需要的高质量的应用软件。

　　因此，在这种情况下，我收回我刚才所说。的确，程序员请求别人的帮助是绝对有益的。事实上，如果你不知道某些知识而你却极力掩饰这种无知，那你就会使你的程序中涉及到这些方面的地方充满了bug(比喻程序的漏洞)。

　　事实上，对IT管理人员和团队领导者来说，引导一种勇于承认自己不知道的知识并请求帮助的团队文化是极为重要的。最好的是向那些高级程序员求助，或者至少是大家都尊重的某个人，率先采取行动,以寻求机会求助于别人

　　一旦团队人员看到队中的“万事通”有些时候也需要帮助，那么他们就会容易做到请求别人帮助了。

　　我们应该总是相信上司吗?

　　如果不是他们年龄都超过30岁。此时大家或许正在惊讶我29岁，已经好多年了。

　　当然，相信上司，只是不要他们说任何话都相信，特别是当伴随着表演的时候

　　我要说的是：正是因为Steven，“世界PL/SQL顶尖专家之一”，在PL/SQL某些方面已经有了相当的经历，这并不意味着你会在你的Oracle版本，或其操作系统等方面将有相同的经历。

　　程序设计中没有信任，无论它是否影响着程序设计。因此任何所谓的专家如果不是认为所有知识都掌握了，就应该编著文章，通过这些文章可以促使自己核实一些提出的观点。

　　我就是试着在这样做，而我的所有文章在Oracle PL/SQL程序设计中是可以用到了，其中包括我的所有研讨会上的发言稿。你可以下载它们并在自己的内部环境中任意使用。用我的资料来授课，在你的代码中使用我的程序，运行我的一些测试代码来测试我的一些论点。

　　审查代码的好处在哪儿?

　　代码审查—让其他人查看并批评你的代码—是可以引起恐慌的，除非在你的团队中存在良好的团队文化。但是，审查代码确实是很重要的。实际上，没有任何代码会在其他人没有看过的情况下被用于产品开发中。一个人陷于需求和程序设计的问题中无法自拔一般有两种途径。

　　即使知道某一天某个人可能看到你写的代码，并能大幅改变其内容和质量。

　　再一点，在实践中审查代码的最好方法是主动找那些最优秀的开发者，请求他们查看你最近的软件作品。这样，意思就很清楚：请查看、批评我的代码并给我反馈。

　　最后，你也可以使用自动的代码审查，例如Toad's Code Xpert功能，将我的 “Oracle PL/SQL 最好的实践”一书中所有建议组合在一起，同时在其基础上加入了许多规则。只需按一下按钮，Code Xpert将会自动分析你的程序，并列出所有如何提高你的代码质量的反馈建议。

        程序员应该隐藏他们代码的一些细节吗?

　　我刚刚谈到了程序员应如何邀请别人审查自己的代码，那么现在说“是的，你应该隐藏你的代码的关键细节”就显得奇怪了，但是我们现在说的确实是另外一件完全不同的事。

　　越来越多人知道“信息隐蔽”，在编写高质量软件过程中这是至关重要的观念。 在写应用软件过程中，基本思想是避免陷于不必要的细节中。我们要把重点放在手头上的任务上，即项目实施需求上。而在项目内部，我们仍然在处理很多的复杂细节。

　　如果你在如何编写代码上不够细心，最后你的代码只能是堆满了bug，无法读懂，很难调试、修改和管理。

　　编写代码的一个比较好的方法是压缩，将复杂的逻辑独立化(如一个模块或过程调用)。这样，你就可以需要时调用这些子程序(模块或过程)，远比将所有的细节堆一起要好得多。换句话说，你通过程序调用将程序的某些细节隐藏了。

　　我已经有了强烈的隐藏意识。我总结的经验(我在训练中把它作为程序员的四个最关键点之一来强烈要求)是没有超过50行代码的执行程序，我一般是20-30行即可。

　　你一定会问“这怎么可能?”。主要是通过可以重复利用的子程序，但是也可以通过循环或者嵌套模块。于是，在我的程序中声明的过程或模块(指定名称或未指定名称)中，我可以继续使用其他的只能在该过程中调用的子程序。

　　我感绝你隐藏的代码越多越好。因此，你可以尽量隐藏的更多，我认为这对很多的开发者来说不是问题。

　　应付软件中存在的漏洞问题最好的方法是什么?

　　去掉bug(漏洞)。

　　这是我目前的困扰(实际上是PL/SQL研究上一般的困扰)：提高PL/SQL程序测试的质量和数量

　　为了减少程序中bug的数量，我认为程序员应该做到一下几点：

　　尽可能地做到标准化。使用标准构件作为代码的底层基础结构(错误管理，SQL访问等)。
　　使用自上而下的设计保持代码逻辑的干净和透明。
　　在执行你的程序之前先测试甚至执行一下你的测试代码。这种方法有一个有趣的称呼，即“测试驱动”
　　尽量将程序单元化并自动化测试。没有自动化，你没有机会把你的代码中多数的bug除掉。PL/SQL中，自动测试的选择是有限的，但同样非常有用。你可以在utPLSQL和Quest Code Tester for Oracle之间选择。
　　utPLSQL是一个Junit的开源框架模型(我1999年写的最初版本)。它提供了一些自动化，但是仍然需要你自己编写测试代码。