Комментарии 8
ошибки уровня джун
Че то не очень понятно со string format - заменили на тормознутую конкатенацию, которую исправляли в другом месте и все залетало?
Упоминание Baeldung уже задолбало. Как и в вашей статье, бесполезная информация исключительно о тривиальных кейсах, зато вылезает первым при каждой попытке поиска.
public String buildOrderSummary(String orderId, String customer, double amount) {
Только меня что ли цепляет использование double для сумм?
Это же такое не паханное поле для потенциальных ошибок финансовых расчетов и вычислений. Да еще не в минимальных единицах валюты суммы.
Как правило (моя статистика), если в API, с которым придется интегрироваться фигурирует суммы в виде <example: “223.1”>, то:
json (иногда xml) описан только как текст/пример в документации (openapi для json и xsd для pdf они не знают)
интеграция будет со страдашками (какая ни будь да дурацкая проблема при интеграции да вылезет сбоку)
Просто потому, что использование чисел с плавающей точкой для финансовых сумм показывает уровень “понимания”
return String.format(“Order %s for %s: $%.2f”, orderId, customer, amount);
Исправление:
return “Order " + orderId + " for " + customer + “: $” + String.format(”%.2f", amount);
А что поменялось? как использовался оооочень тормозной String.format, так и используется.
String.format лучше вообще завезти себе в мозгу как табу на использование.
А еще завести за правило писать
if (log.isTraceEnabled()) {
log.trace(… объекты с тяжелым toString()…)
}
Как бы в целом статья правильная. Но вот чет режет глаз некоторые такие огрехи. Впрочем, “в чужом глазу соринку…”.
Ну или log.atTrace(): в случае отключенного TRACE вернёт no-op реализацию через синглтон. В случае использования Slf4j с новым API.
https://github.com/qos-ch/slf4j/blob/61400453cd366f227dbc36036d6ac128a36da59b/slf4j-api/src/main/java/org/slf4j/Logger.java#L256
Проблема с логами ещё может быть в том, что много лишних строковых объектов создаётся ещё до вызова метода, так что реализация, которая просто ничего не делает, в этом случае не поможет.
Тут либо в условие оборачивать, либо принимать Supplier<String>, который будет делать строку только если его со стороны логгера попросят.
Тут недавно была статья на схожую тему.
Правильное решение сделать параметризованные сообщения, где конкатенация происходит только если логер действительно будет писать сообщение:
logger.debug("Processing event {} at {}", event.getId(), Instant.now());Ну или вот так:
log.atDebug()
.addArgument(event::getId)
.addArgument(Instant::now)
.log("Processing event {} at {}");Впрочем, method reference там необязателен, т.к. https://github.com/qos-ch/slf4j/blob/61400453cd366f227dbc36036d6ac128a36da59b/slf4j-api/src/main/java/org/slf4j/spi/DefaultLoggingEventBuilder.java#L81 сразу начнёт вычисление аргумента. Впрочем, если уровень DEBUG будет отключен: то ничего делать не будет.
Зато если method reference тяжел для вычисления, то метод вызываться не будет в случае noop реализации.
Java — быстрая. Ваш код может таким не быть