使我哭泣的代码

我的一个朋友最近告诉我他目前在维护的旧应用程序中遇到的问题。 这是一段示例代码，用以说明我在说什么：

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

立刻让我哭了。 如果只是一个示例，我可以想象该应用程序其余部分的外观。 事实上，这些问题正是他认为自己需要首先解决几件事的根本原因，甚至还没有考虑在该应用程序中引入jOOQ或任何其他新技术。 是的，有一些严肃的教导要做（或打耳光？）

如果到目前为止您在不了解我在说什么的情况下通读了这篇文章，那么让我给您一些建议。 请遵循以下建议，以防止我的朋友跳出窗口：

切勿将这种琐碎的逻辑发送到数据库中执行！

我最近在博客中写道， 您应该计算/执行数据库中的某些内容的 各种原因 。 简单的字符串替换不是其中之一！ 哎呀，为什么要冒着数据库往返/网络延迟，连接和/或数据传输超时以及各种其他可能用Java编写的东西的风险？

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

该方法甚至具有与 SQL函数相同的名称 。 哎呀，为什么还要为此使用可怕的JDBC API呢？ 亲爱的开发人员，请。 花1h并研究java.lang.String可用的方法的整个列表。 真是太棒了，完全被低估了！

切勿重新格式化以前格式化的数据

这是一条经验法则：数据格式化后，将永远丢失并且无法用于计算/数据处理。 任何人都可以格式化任何数据的原因只有一个简单的原因。 用于向人类显示数据。 人类不擅长破译或记忆像

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

人类擅长阅读和记忆以下内容：

My wife's bank account

所以在我后面重复一遍。 数据格式化后，将永远丢失并且无法用于计算/数据处理。 如果格式有任何错误，请在错误的地方修复格式。 切勿重新格式化以前格式化的数据。 决不。

永远不要在数据访问层中格式化数据

就像人类对使用长技术ID的操作极为不利，而机器对格式化数据的操作极其不利。 实际上，在数据访问层中格式化数据的理由很少，以至于您甚至都不应该想到。 一个可以接受的原因是，当您有一个非常复杂，经过高度调整的报表在数据库中运行时。 但是您没有这个功能，因为您考虑过使用SQL replace()函数从Java字符串中删除空格。 那不是完全复杂的报告。

因此，请阅读我。 除非您有令人信服的技术原因，否则切勿在数据访问层中格式化数据。 在整个应用程序中，您的accountNo应该保持尽可能原始，技术性和ID风格。 在accountNo到达用户界面之前，绝对不需要格式化它以供人类使用。

好吧，公平地说，该规则还有另一个例外。 当您选择在UI中对数据进行排序时，您可能希望按accountNo的格式化版本对数据进行排序，因为排序结果将由人类使用：

SELECT ..
FROM accounts a
ORDER BY a.account_no_formatted

偷懒

成为更好的程序员的一种非常简单的方法：懒惰。 懒得编写10行代码来用"- "简单地替换"-" 。 通过如此令人难以置信的懒惰，您将始终认为：

必须有写这个更好的方法

不知道并没有错。 但是，使用最小阻力的路径并为此编写一些琐碎的东西要编写10行代码，这一切都是错误的。 相信我。 一旦可以用单行代码编写琐碎的东西，您的生活就会好得多。 您可以再次专注于业务逻辑。

参考： JAVA，SQL和JOOQ博客上的JCG合作伙伴 Lukas Eder令我哭泣的代码 。

翻译自: https://www.javacodegeeks.com/2013/11/the-code-that-made-me-cry.html