http://www.csdn.net/article/2013-11-08/2817433-code-made-me-cry
摘要：作者Lukas Eder发表了一篇文章《code-made-me-cry》，引发了开发者们的广泛讨论及思考。在他看来，阻力最小的路径通常是一切错误的根源。因此，即便是为琐碎的应用编写10行代码也是值得的。
作者Lukas Eder发表了一篇文章《code-made-me-cry》，引发了开发者们的广泛讨论及思考，我们一起来看下（以下是译文）。
我的一位朋友告诉我，他最近遇到关于正在维护的遗留应用程序的一些问题。下面的这段代码就能说明我们正在讨论的内容：
|
1
2
3
4
5
6
7
|
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就可以完成的事情？
|
1
|
accountNo.replace("- ", "-"); |
这里，我们还能采用SQL函数命名的方法。为什么要经历使用JDBC API这么繁琐的过程？亲爱的开发者们，利用1小时来研究java.lang.String可用的方法列表吧，这个方法看起来很棒，千万别低估了类！
2. 切勿格式化已格式过的数据
这是条经验法则：一旦数据被格式化，那么它就永远丢失了且不可用于计算/数据处理。
这就是为什么没有任何人想要格式化数据的原因。通常这些数据是为了显示给人们看的，因为人们并不善于破译或记忆这些数据。
|
1
|
a56225e0-45ef-11e3-8f96-0800200c9a66 |
相反的，人们更擅于阅读且记忆类似这样的：
|
1
|
My wife's bank account |
正如前面所说的，一旦数据被格式化，那么它就永远丢失了且不可用于计算/数据处理。如果在格式化过程中出现错误，那么修复格式化也是错误的。因此，永远不要格式化已经格式过的数据。
3. 切勿在数据访问层中格式化数据
正如人们不擅长操作比较长的特有ID一样，机器也不擅长操作格式化数据。事实上，在数据访问层进行格式化是有理由的，也许你还未遇到过。当然，一个可以接受的理由是你在DB中需要运行一个非常复杂的、高度优化报告。但通常你不会这么做，这是因为你会考虑从Java字符串中使用 SQL replace() 函数来删除空格，这并不是个复杂的报告。
因此，永远不要在数据访问层中格式化数据，除非你拥有一个令人信服的技术。accountNo应该保持不变，ID-style尽可能地贯穿整个应用。在accountNo干扰UI之前，完全没必要去格式化数据。
OK，说句公道话，也不是没有例外。假如当你选择在UI中进行数据排序，那么你可能想通过格式化各种accountNo来进行数据排序，排序结果正如下面所例举的这样：
|
1
2
3
|
SELECT ..FROM accounts aORDER BY a.account_no_formatted |
4. 懒惰
这里有个非常简单的方式来帮助你成为更加优秀的程序员——偷懒。
由于太懒以至于无法将“- “替换为“-”。正是由于太懒，你甚至还会认为：
|
1
|
There HAS to be a better way to write this。总会有更好的方式来编写这个。 |
阻力最小的方法往往容易出错，但也不应该为如此琐碎的事情编写10行代码。一旦你能够用1行代码来解决琐碎的事情，那么，你的生活会变得更好。