Статьи

Кодекс, который заставил меня плакать

Июнь 4, 2018

Мой друг недавно рассказал мне о проблемах, с которыми он в настоящее время борется в унаследованном приложении. Вот пример кода, иллюстрирующий то, о чем я говорю:

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

Это сразу заставило меня плакать. Как в коде, который заставил меня плакать , или #CTMMC . Если это всего лишь пример, я могу представить, как выглядит остальная часть приложения. На самом деле, именно эти проблемы и стали причиной, по которой он решил сначала разобраться с несколькими вещами, прежде чем он мог даже подумать о внедрении jOOQ  или любой другой новой технологии в это приложение. Да, есть какое-то серьезное учение (или шлепки?)

Если вы до сих пор читали эту статью, не зная, о чем я, то позвольте мне дать вам несколько советов. Пожалуйста, следуйте этому совету, чтобы мой друг не выпрыгнул из окна:

НИКОГДА не отправляйте такую ​​тривиальную логику в базу данных для исполнения!

Недавно я писал в блоге о различных причинах, почему вы должны рассчитывать / выполнять  некоторые вещи в базе данных. Простая  замена строки не является одной из таких вещей! Черт, зачем рисковать обходом базы данных / задержкой в ​​сети, таймаутами соединения и / или передачи данных, и всякими другими вещами для чего-то, что могло бы быть написано как таковое в Java?

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

Метод даже имеет то же имя, что и функция SQL. Черт возьми, зачем даже пытаться использовать ужасный JDBC API для этого? Пожалуйста, уважаемый разработчик. Возьмите 1 час и изучите весь список доступных методов java.lang.String. Это такой классный и совершенно недооцененный класс!

НИКОГДА не переформатируйте ранее отформатированные данные

Это практическое правило: как только данные отформатированы, они навсегда теряются и становятся недоступными для вычислений / обработки данных. Есть только одна простая причина, почему кто-либо когда-либо отформатирует данные Это для отображения данных для людей. Люди плохо разбираются или запоминают такие вещи, как

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

Люди хорошо читают и запоминают такие вещи, как:

My wife's bank account

Так повторяй за мной. Как только данные отформатированы, они навсегда теряются и недоступны для вычислений / обработки данных. Если форматирование было неправильным в любом случае, тогда исправьте форматирование, где это неправильно. НИКОГДА не переформатируйте ранее отформатированные данные. НИКОГДА.

НИКОГДА не форматировать данные на уровне доступа к данным

Так же, как люди невероятно плохо работают с длинными техническими идентификаторами, машины невероятно плохо работают с отформатированными данными. На самом деле, существует так мало причин когда-либо форматировать данные на уровне доступа к данным, что вам, вероятно, это даже не придет в голову. Одной из приемлемых причин является то, что у вас есть очень очень сложный, сильно настроенный отчет, который выполняется в БД. Но у вас этого нет, потому что вы рассматривали возможность использования replace()функции SQL для удаления пробелов из строки Java. Это не совсем сложная отчетность.

Так что читайте за мной. НИКОГДА не форматируйте данные на уровне доступа к данным, если у вас нет веских технических причин для этого. Ваша учетная записьНо должна оставаться как можно более нетронутой, в техническом и идентификационном стиле как можно дольше на протяжении всего вашего приложения. Нет абсолютно никакой необходимости форматировать его для потребления человеком, прежде чем учетная запись не попадет в пользовательский интерфейс.

ОК, если честно, есть еще одно исключение из этого правила. Когда вы выбираете сортировку данных в пользовательском интерфейсе, вы можете отсортировать данные по отформатированной версии accountNo, так как результат сортировки будет потребляться человеком:

SELECT ..
FROM accounts a
ORDER BY a.account_no_formatted

Быть ленивым

Есть один очень простой способ стать лучшим программистом: быть ленивым. Будьте ленивы, чтобы написать 10 строк кода для простой замены "- "на "-". Будучи невероятно ленивым, вы всегда будете думать:

Там HAS быть лучшим способом , чтобы написать это

Нет ничего плохого в том, что ты не знаешь. Но все неправильно с использованием пути наименьшего сопротивления и написанием 10 строк кода для чего-то столь же тривиального, как этот. Поверь мне. Ваша жизнь станет намного лучше, когда тривиальные вещи могут быть написаны в одну строку. Вы можете снова сосредоточиться на своей бизнес-логике.

33
Share: