百度在我肩上哭泣英文_使我哭泣的代码-CSDN博客

百度在我肩上哭泣英文

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

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到达用户界面之前，绝对不需要格式化它以供人类使用。

好吧，公平地说，该规则还有另一个例外。当您选择在用户界面中对数据进行排序时，您可能希望按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

百度在我肩上哭泣英文