1.6 一些建议
Oracle PL/SQL程序设计（第5版）
自从本书1995年第一版出版以来，我有机会培训、帮助、与上千名PL/SQL开发人员合作过。在这个过程中，我从学生和读者中学到的许多，也深刻的理解了在PL/SQL世界中我们是如何工作的。我要给你一些如何让这个强大的编程语言更有效的工作的建议，你可不要不耐烦。
1.6.1 不要太着急
我们的工作时间总是很紧迫，记者解决一个个的问题。我们不能浪费时间，有太多的代码要写。因此马上开始吧——对吗？
错误。如果太快地深入到代码构建中，盲目地把用户需求转化成成百上千甚至上万行代码，最终我们得到是一大堆乱七八糟的、基本不可能调试和维护的垃圾。不要对即将到来的最后期限太过恐慌；如果我们能够做一些仔细的计划，就能够保证最后期限。
我强烈地建议你一定要抵制住这些时间压力，确保在开始开发新应用，甚至应用中的一个程序之前都有完成下面这些事情：
在开始编写代码之前构建测试用例和测试脚本
就算我们的程序只有一行代码，我们也需要先确定如何才能验证这个实现方式是成功的。只有这样，我们才能保证程序接口的正确性，也才能更透彻地知道我们的程序到底要做些什么事情。
就开发人员该如何编写SQL语句制定一个清晰的规则
一般来说，我建议每个开发人员都不要写太多的SQL。相反，那些单行结果的查询和插入、更新操作都应该“藏在”一个预建的、经过彻底测试的过程和函数的背后（这种方法也叫做数据封装）。这些程序可以比那些散布在代码中到处都是的SQL语句（很多语句都是重复的）更有效的优化、测试以及维护。
**
就开发人员如何处理应用中的异常指点一个清晰的规则**
一个开发团队中的所有开发人员都应该用相同的方式抛出、处理、记录错误。要想这么做，做好的方法就是创建一个单独的错误处理包，报所有关于保留错误日志、确定异常如何抛出、以及如何传播出嵌套块的细节都隐藏起来。一定要确保团队中的所有开发人员都要使用这个包，而不是自己又写一套复杂的、浪费时间的、还容易出错的错误处理代码。
使用“逐步细化”（也叫做自顶向下的设计）的方法，避免任何时间我们必须处理的需求过于复杂
如果我们采用这种方法，就会发现模块中的执行单元变得很短而且更容易理解，这也能保证我们的代码更易于维护和改进。局部或者嵌套模块在这个设计原则中起着关键角色。
这些只是我们开始代码编写之前必须要注意事项的一部分。记住：在软件开发世界里，仓促上马不仅意味着浪费资源，肯定会有大量的bug，周末也没了。
1.6.2 不要怕寻求帮助
如果你是一个软件专业人士，你很可能是一个相当聪明的人。你学习刻苦、勤学苦练，为了良好生活而写代码。你差不多可以解决任何交给你的问题，这让你很骄傲。不幸的是，你的成功也让你自负、自大、遇到困难也不愿意寻求帮助，对于软件开发来说这是最危险也是最有破坏性的方面之一。
软件都是由人编写的；因此，很重要的一点就是，要认识到人类心理在软件开发中扮演了一个关键的角色。下面就是例子。
Joe，是一个6人开发团队中的高级开发人员，编程中遇到了一个问题。他花了数个小时研究这个问题，只有越来越多的挫折，可还是不能指出问题的来源。他不想向他的组员寻求版主因为他们的经验比他少。不过，最后他还是无计可施只能“放弃了”。叹了口气，他拿起了电话按了个键：“Sandra，你能过来看看我的程序吗？我有个问题无法解决。”Sandra过来了，很快地看了下Joe的程序，指出了很早之前就应该发现的问题。万岁！程序解决了，Joe感谢万分，但实际上私底下他还是很尴尬的。
类似于“我怎么就没看到呢？”以及“只要我肯在花上5分钟时间调试，我自己就能解决了”的想法不断地出现在Joe的脑海中。这很容易理解不过也很愚蠢。因为我们和代码太近了，以至于发现不了问题。有时，我们所需要的就是一个全新的角度，没有任何关系的人的相对客观的看法。这和资历、专业或者能力没有任何关系。
我强烈建议你应该在你的机构内建立下面这些指导原则：
奖励那些承认自己不知道的
明明不了解某个应用程序或者其代码又不说，这是很危险的。培养一种欢迎别人质疑以及求助的文化氛围。
**
寻求帮助**
如果我们无法在30分钟内找出问题所在，立即请别人帮忙。我们甚至可以建立一套“互助系统”，给每个人都分配一个他可以需求帮助的人。不要自己（或者小组中的其他人）徒劳地花费数小时却没有任何结果。
**
设置一个正式的同行代码评审程序**
当我们的代码还没有小组其他成员阅读或者评论（以一种积极的、建设性的方式）之前，不要把代码提交给QA或者生产线上。
1.6.3 采用一种创建新的甚至激进的方法
我们在生活中总是重蹈覆辙。人是一种习惯性的生物：我们学习用一种方式编写代码；我们承认产品有一些局限；我们不做任何严格的检查就排除可能的解决办法，仅仅因为我们以为不能。开发人员逐渐对他们自己的程序偏信，经常是肯定的一面。总会听到他们这么说：
“不可能跑得更快了；它只是只猪啊”。
“我没法让它按照用户需要的那样工作，我们必须要等到下一个版本。”
“如果我用X或者Y或者Z，就易如反掌。不过要是用这个，那就像打仗一样了。”
但事实上，我们的程序总是可以更快一点。事实上屏幕也可以像用户希望的那样工作。尽管每个产品都有自己的局限性、优势和弱势，我们也不能够等着下一版。如果能告诉医生正确的面对问题，不接受任何借口，精心设计一个方案是不是会很爽？
我们该怎么做呢？打破那些已经僵化的意见的限制，重新看看世界（或者只是你的办公室）。重新评估我们已经养成的编程习惯。要有创造性——逐步地摆脱传统方法，逐步摆脱那些在我们日常工作中不断强化的局限的、机械的方法。
做些新的尝试：试试那些看起来离经叛道的方法。你会惊奇地发现，作为一个程序员乃至问题解决员你会学到多少东西。这么多年来，我一次又一次惊异地发现，一旦我不再说“你不能这么做”，而只是静静地点头，默默地对自己说“现在，如果我这么做……”，也真的就实现了。