说三道四技术文摘-感悟人生的经典句子
说三道四 > 文档快照

一段代码引发的思考

HTML文档下载 WORD文档下载 PDF文档下载
作者Lukas Eder发表了一篇文章《code-made-me-cry》,引发了开发者们的广泛讨论及思考。在他看来,阻力最小的方法往往容易出错,但也不应该为如此琐碎的事情编写10行代码。

作者Lukas Eder发表了一篇文章《code-made-me-cry》,引发了开发者们的广泛讨论及思考,我们一起来看下(以下是译文)。

我的一位朋友告诉我,他最近遇到关于正在维护的遗留应用程序的一些问题。下面的这段代码就能说明我们正在讨论的内容:

String q = "select replace('" +              accountNo +              "%','- ','-') from dual";rs = stmt.executeQuery(q);if (rs.next()) {accountNoFormatted = rs.getString(1);}

看到这,瞬间让我感到欲哭无泪。如果这只是一个简单的示例,那么我能想象出该应用程序剩余部分是怎样的。事实上,再找出这些问题的缘由前,首先应确定为何他需要这些事项,他(我的朋友)甚至考虑在该应用中引入jOOQ或者其他新技术。

下面是一些关于如何在应用程序中操作数据库的建议:

1.不要给数据库发送过类似这样的琐碎逻辑( trivial logic 

我曾经在博客中发表了《10 Common Mistakes Java Developers Make when Writing SQL》。感兴趣的不妨移步去看看。尽管是一段简单的字符串替换,但并非是小事。为什么要冒着数据库往返/网络延迟、数据库连接或者数据传输超时,或者各种问题可能发生的风险去让数据库做一些Java就可以完成的事情?

accountNo.replace("- ", "-");

这里,我们还能采用SQL函数命名的方法。为什么要经历使用JDBC API这么繁琐的过程?亲爱的开发者们,利用1小时来研究java.lang.String可用的方法列表吧,这个方法看起来很棒,千万别低估了类!

2. 切勿格式化已格式过的数据

这是条经验法则:一旦数据被格式化,那么它就不可用于计算/数据处理。

这就是为什么没有任何人想要格式化数据的原因。通常这些数据是为了显示给人们看的,因为人们并不善于破译或记忆这些数据。

a56225e0-45ef-11e3-8f96-0800200c9a66

相反的,人们更擅于阅读且记忆类似这样的:

My wife's bank account

正如前面所说的,一旦数据被格式化,那么它就不可用于计算/数据处理。如果在格式化过程中出现错误,那么修复格式化也是错误的。因此,永远不要格式化已经格式过的数据。

3. 切勿在数据访问层中格式化数据

正如人们不擅长操作比较长的特有ID一样,机器也不擅长操作格式化数据。事实上,在数据访问层进行格式化是有理由的,也许你还未遇到过。当然,一个可以接受的理由是你在DB中需要运行一个非常复杂的、高度优化报告。但通常你不会这么做,这是因为你会考虑从Java字符串中使用 SQL replace() 函数来删除空格,这并不是个复杂的报告。

因此,永远不要在数据访问层中格式化数据,除非你拥有一个令人信服的技术。accountNo应该保持不变,ID-style尽可能地贯穿整个应用。在accountNo干扰UI之前,完全没必要去格式化数据。

OK,说句公道话,也不是没有例外。假如当你选择在UI中进行数据排序,那么你可能想通过格式化各种accountNo来进行数据排序,排序结果正如下面所例举的这样:

SELECT ..FROM accounts aORDER BY a.account_no_formatted

4. 懒惰

这里有个非常简单的方式来帮助你成为更加优秀的程序员——偷懒。

由于太懒你不会将 "- " 替换为"-",为这样的小事编写10行代码。你甚至还会认为:

There HAS to be a better way to write this。总会有更好的方式来编写这个。

阻力最小的方法往往容易出错,但也不应该为如此琐碎的事情编写10行代码。一旦你能够用1行代码来解决琐碎的事情,那么,你的生活会变得更好。

英文出自:Dzone

备案号:鲁ICP备13029499号-2 说三道四 www.s3d4.cn 说三道四技术文摘