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

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

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

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

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

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

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

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

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

　　去掉bug(漏洞)。

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

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

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