《Oracle PL/SQL程序设计(第5版)》一一1.6 一些建议

  1. 云栖社区>
  2. 博客>
  3. 正文

《Oracle PL/SQL程序设计(第5版)》一一1.6 一些建议

异步社区 2017-05-02 14:05:00 浏览903
展开阅读全文

本节书摘来自异步社区出版社《Oracle PL/SQL程序设计(第5版)》一书中的第1章,第1.6节,作者:【美】Steven Feuerstein , Bill Pribyl,更多章节内容可以访问云栖社区“异步社区”公众号查看。

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,就易如反掌。不过要是用这个,那就像打仗一样了。”

但事实上,我们的程序总是可以更快一点。事实上屏幕也可以像用户希望的那样工作。尽管每个产品都有自己的局限性、优势和弱势,我们也不能够等着下一版。如果能告诉医生正确的面对问题,不接受任何借口,精心设计一个方案是不是会很爽?

我们该怎么做呢?打破那些已经僵化的意见的限制,重新看看世界(或者只是你的办公室)。重新评估我们已经养成的编程习惯。要有创造性——逐步地摆脱传统方法,逐步摆脱那些在我们日常工作中不断强化的局限的、机械的方法。

做些新的尝试:试试那些看起来离经叛道的方法。你会惊奇地发现,作为一个程序员乃至问题解决员你会学到多少东西。这么多年来,我一次又一次惊异地发现,一旦我不再说“你不能这么做”,而只是静静地点头,默默地对自己说“现在,如果我这么做……”,也真的就实现了。

网友评论

登录后评论
0/500
评论
异步社区
+ 关注