Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 15
Первая —
catch (Exception e)глотает абсолютно всё, включаяOutOfMemoryError-обёртки
можно поподробнее что имеете в виду? это же не Throwable
Формулировка задания и ожидаемые ответы как-то не соответствуют друг другу.
Считаются найденными только те, что вы можете объяснить вслух: почему это баг, что произойдёт в проде, как исправить
Тут прям большой акцент на том, что искать нужно только баги, которые вызывают проблему на проде. И первым же пунктом история про Autowired vs constructor injection, которая не является багой и не вызывает проблем на проде. Это уже скорее стилевая проблема, а такие проблемы довольно неоднозначные. Если уж в них закапываться, то тут вам и отсутствие интерфейса, и Map в качестве body, и error reporting в случае всяких bad request’ов никакой, и метрик нет, и т.д. В общем, тут только на таких проблемах легко за 8 можно выйти.
Ну и ожидать, что кандидат прочитает ваши мысли и догадается, что AntifraudClient - это хождение в соседний сервис по http - это, имхо, такое себе. Точно так же можно и NotificationService заподозрить за хождением в соседний сервис. Тем более, что к интерфейсу AntifraudClient возвращающему “OK” строкой в принципе есть вопросики.
Про кеш вообще бред какой-то, ибо это не кеш, а непонятно что - в него пишут, но не читают. Его так-то просто удалить нужно, а не на кофеин менять.
В целом - неплохо, но разбор оставляет ощущение, что ожидалось, что кандидат должен мысли интервьюера прочитать.
А еще:
этот кэш для каждого инстанса свой,
на api отсутствует версионность,
полное отсутствие контроля входных данных на уровне контроллера,
Сам контроллер, по-хорошему, должен проверять авторизацию, валидировать входные данные, выделять тред на выполнение запроса, но не содержать в себе бизнес-логику,
В примерах упущены фигурные скобки на однострочные блоки кода,
Неспецифический RuntimeException для весьма понятной ошибки. В той же кибане проще будет собирать статистику по специфичным ошибкам,
… и так далее.
В целом - все не так плохо, можно довольно быстро поправить, причем стандартные линтеры (Sonar, Qodana) отловят заметную часть этих проблем.
Бывает, дают такие примеры, что аж руки опускаются, насколько все запутано.
А что-то аналогичное есть в виде книги?
Ощущение, что написано пополам с нейронкой. Сам по себе набор ошибок подобран неплохо. Есть вопросы к реализации.
Я правильно понимаю, что транзакция в create() никогда не откатится, потому что обёртка реагирует на исключения, а вы их все проглотили? Это не упоминается в тексте, хотя кажется серьёзным дефектом.
sendNotification() по неймингу выглядит как отправка сообщения во внешний канал, где транзакция в принципе бессмысленна, а не запись в бд.
Про кеш упомянули - непонятно зачем он и как вообще используется.
Набор ошибок хороший, пример стоит доработать.
Спасибо за код. Если это действительно из собесов, то тут поле не паханное))
Каюсь, сначала нашел не то что вы указали)
Но предлагаю в список добавить и эти (сори не читал комментарии может уже что-то есть):
Отсутствие версионирования (/v1/payments) - API без версии ломает обратную совместимость при любом изменении. Клиенты, завязанные на этой версии, перестанут работать. Вообще показывает способность к расширениюResponseEntity<?>
сырой дженерик теряет информацию о типе тела ответа. В Swagger/OpenAPI это превратится в object, клиенты не смогут сгенерировать типизированные модели @RequestBody Map<String, Object>
теряется контракт API. Нет @Valid, нет документации полей, нет контроля типов. Любое изменение структуры ломается в рантайме ClassCastExceptionnew Date()java.util.Date - мутабельный, устаревший класс, не рекомендуется к использованию хотя и допустимфp.setStatus("PENDING")
строковый литерал для статуса - это нонсенс. Опечатка ("PENING") не будет поймана компилятором, думаю выводы сделаете сами)!"OK".equals(r)
Не совсем плохо но лучше - !Objects.equals("OK", r), более явно проверяет что r != null
Вызов kafka.send без обработки результата
метод асинхронный, но исключения теряются. Нужно добавить callback или использовать синхронную отправку.RuntimeException - слишком общее исключение. Оно не говорит вызывающему коду (и глобальному обработчику) о том, что именно пошло не так. Лучше - кастомную
Далее более архитектурная проблема:@Transactional на методе контроллера и отсутствие сервисного слоя
Когда вы ставите @Transactional на контроллер, контроллер берёт на себя ответственность за управление транзакциями - это нарушает принцип SR
Что ждет с таким подходом:
- нормально не протестировать - придется кучу зависимостей тянуть и все либо мокать либо подымать
- невозможно переиспользовать логику, для написания похожей обработки - новая ручка
- расширение приведет только к росту проблем
Вообще, обычно в контроллере нет такой каши - вся логика должна быть вынесена в сервис. И однобуквенных переменных быть не должно. Ну и так, по мелочи - в @RequestMapping в пути отсутствует версия api
Вот так ответила локальная gemma-4-12B-it-Q5_K_M:
1. Архитектурные проблемы (High Severity)
А. Проблема "Dual Write" (Консистентность данных)
Почему это баг: Код пытается одновременно обновить базу данных (
repo.save), отправить сообщение в Kafka (kafka.send) и отправить уведомление (notifications.send). Эти системы не связаны в единую распределенную транзакцию.Что произойдет в проде: Если
repo.save(p)пройдет успешно, но Kafka упадет или произойдет сетевой сбой при отправке сообщения, платеж будет создан в БД, но система обработки заказов/логистики его не увидит. И наоборот: сообщение уйдет, а транзакция в БД откатится. Это приведет к "фантомным" платежам или потере заказов.Как исправить: Использовать паттерн Transactional Outbox. Сохраняйте событие (сообщение для Kafka) в ту же БД в рамках одной транзакции с платежом. Отдельный сервис (Relay) будет читать эти события и отправлять их в Kafka.
Б. Самовызов транзакционного метода (Self-invocation)
Почему это баг: Метод
sendNotificationпомечен@Transactional(propagation = Propagation.REQUIRES_NEW), но он вызывается внутри методаcreateчерезthis.sendNotification(p).Что произойдет в проде: Spring использует AOP-прокси для управления транзакциями. При вызове через
thisпрокси-объект обходится, и аннотация@Transactionalигнорируется. Уведомление будет выполняться в той же транзакции, что и основной методcreate. Если уведомление упадет, откатится весь платеж (и наоборот).Как исправить: Вынести
sendNotificationв отдельный сервис (например,NotificationServiceили новыйNotificationManager) и внедрить его в контроллер.
В. Утечка соединений БД (Connection Pool Exhaustion)
Почему это баг: Аннотация
@Transactionalстоит на всем методеcreate. Внутри этого метода вызываетсяantifraud.check(p). Если внешний сервис антифрода работает медленно (например, 2-5 секунд), соединение с базой данных будет удерживаться всё это время.Что произойдет в проде: При росте нагрузки количество свободных соединений в пуле (HikariCP) быстро закончится. Система начнет выдавать ошибки
ConnectionTimeout, и приложение перестанет принимать новые платежи.Как исправить: Вынести вызов
antifraud.check(p)за пределы транзакции. Сначала проверяем антифрод, и только если он "OK", открываем транзакцию для сохранения в БД.
2. Проблемы многопоточности и памяти (Medium/High Severity)
А. Непотокобезопасный кэш и утечка памяти
Почему это баг:
private static Map<UUID, Payment> cache = new HashMap<>();Что произойдет в проде:
Race Condition:
HashMapне потокобезопасна. Одновременная запись из разных потоков может привести к бесконечному циклу (зависание CPU) или повреждению структуры данных.Memory Leak: Карта никогда не очищается. С каждым новым платежом память будет забиваться, пока приложение не упадет с
OutOfMemoryError.
Как исправить: Использовать распределенный кэш (Redis) или локальный кэш с политикой вытеснения и TTL (например, Caffeine или Guava Cache).
3. Проблемы кода и данных (Medium Severity)
А. Использование double для финансовых операций
Почему это баг: Тип
doubleиспользует двоичную плавающую запятую, которая не может точно точно выразить десятичные дроби (например,0.1 + 0.2 != 0.3).Что произойдет в проде: Накопление микроскопических ошибок при расчетах. В финансовой системе это недопустимо и приведет к расхождениям в балансах.
Как исправить: Использовать
BigDecimalс указаниемRoundingMode.
Б. Слабая типизация входных данных
Почему это баг: Использование
Map<String, Object> bodyи ручное приведение типов(double) body.get("amount").Что произойдет в проде: Если клиент пришлет число как целое (Integer) в JSON,
body.get("amount")вернетInteger, и попытка привести его кdoubleвызоветClassCastException(500 ошибка). Также нет валидации (например, отрицательныйamount).Как исправить: Создать DTO класс (например,
PaymentRequest) с использованием@Validи аннотаций@Positive,@NotNull.
В. Некорректное логирование и обработка ошибок
Почему это баг:
e.printStackTrace()иreturn ... body(e.getMessage()).Что произойдет в проде:
printStackTrace()не пишет в стандартные системы сбора логов (ELK, Graylog) и не позволяет фильтровать ошибки.e.getMessage()может содержать конфиденциальные данные (SQL ошибки, пути к файлам, данные БД), что является дырой в безопасности.
Как исправить: Использовать SLF4J (
log.error("...", e)), создать@ControllerAdviceдля обработки исключений и возвращать клиенту понятный, безопасный код ошибки.
Г. Использование System.out.println
Почему это баг: Это синхронная операция, которая может замедлять работу приложения под нагрузкой.
Что произойдет в проде: Засорение стандартного вывода и потеря возможности управлять уровнем логирования.
Как исправить: Заменить на
log.info().
Резюме (Checklist для рефакторинга):
Заменить
doubleнаBigDecimal.Заменить
Map<String, Object>наPaymentRequestDTO.Вынести
antifraud.checkза пределы@Transactional.Перенести
sendNotificationв отдельный сервис.Удалить
static HashMapи заменить на Redis/Caffeine.Реализовать Transactional Outbox для Kafka.
Заменить
System.outиprintStackTraceна нормальный логгер.Добавить валидацию входных данных.
Jun 9, 2026, 10:30 AM
31 tokens/sec
(3208 tokens)
ibm-granite_granite-4.1-8b-Q6_K_L/ibm-granite_granite-4.1-8b-Q6_K_L нашла 10!
Общие рекомендации для продукта
Export
КатегорияРекомендацияПричинаПример реализацииВалидацияДобавить @Valid и DTO для запросаУстранить неопределенность типов и отсутствие проверок@Valid @RequestBody PaymentRequest bodyЛогированиеЗаменить System.out на SLF4JУлучшить контроль уровней и централизацию логовlogger.info("Large payment: {}", amount);ТранзакцииСделать sendNotificationчастью одной транзакции или очистить кэш при ошибкеИзбежать несогласованного состояния@Transactional на sendNotificationКэшИспользовать Spring Cache или ConcurrentHashMapс TTLУстранить гонки и утечки памяти@Cacheable("payments")ИдемпотентностьТребовать Idempotency-KeyПредотвратить дубликаты платежей@RequestHeader("Idempotency-Key")Обработка исключенийРазделить перехваты на конкретные типыПредоставить точные ошибки клиентамcatch (AntifraudException e) { … }Сообщения KafkaОтправлять структурированный JSON без PIIСоответствовать требованиям безопасностиkafka.send("payments", new PaymentEvent(...))Повторы/Обратный отсчетДобавить Retry и Backoff для асинхронных вызововУстойчивость к временным сетевым сбоям@Retryable(...)МониторингЭкспортировать метрики (создание платежей, успех антифрауда, задержки Kafka)Повысить отказоустойчивость и быстрое реагированиеSpring Actuator, Prometheus
Применение этих исправлений сделает контроллер PaymentController более надежным, масштабируемым, соблюдающим требования безопасности и легко тестируемым в производственной среде.
Jun 9, 2026, 10:42 AM
29 tokens/sec
(3457 tokens)
if (opt.isPresent()) ... else ... вместо .map().orElseGet()
Придираться к таком эту уже жлобство.
У HikariCP по дефолту в пуле двадцать соединений
10
Благодарю, набор вполне стандартный и полноценный. Тут вдогонку еще валидация amount на уровне API, Map лучше в ДТО. Еще - сервис уведомлений - черный ящик. Важен контекст. Здесь они отправляются сразу, или кладутся куда-нибудь в Redis, например? Тут может потребоваться его отмена в случае отката, то есть компенсирующая операция.
Новая модель на более мощном оборудовании нашла 15 проблем:
source_note: “[[код_собеседования_T-Bank.txt]]” processed_at: 2026-08-10 10:16:39 type: analysis
Ниже представлен детальный анализ кода с точки зрения промышленной разработки, архитектуры и эксплуатации в production.
1. Потокобезопасность и утечка памяти кеша (HashMap)
Почему это ошибка: HashMap не является потокобезопасным. В продакшене один экземпляр приложения обрабатывает десятки/сотни параллельных запросов. Статический кеш разделяется между всеми потоками. Что произойдёт в проде: При конкурентном доступе возникнут ConcurrentModificationException, потеря или дублирование записей. Кеш не имеет TTL/eviction, что приведёт к утечке памяти и eventual OutOfMemoryError. Кеш бесполезен при горизонтальном масштабировании (каждый инстанс хранит свои данные). Исправление: Удалить кеш из контроллера. Для кэширования использовать Redis или Caffeine/Guava Cache с политикой вытеснения и TTL. В платежной системе кеш часто избыточен.
2. Использование double для денежных сумм
Почему это ошибка: double работает с плавающей запятой и имеет ошибки округления. Деньги требуют точности до последнего цента/копейки. Что произойдёт в проде: Несоответствие сумм в логах и БД, финансовые расхождения при агрегации, ClassCastException при получении целого числа из JSON (например, "amount": 1000 будет десериализовано в Integer). Исправление: Заменить на BigDecimal на уровне DTO, сущности и репозитория.
3. Отсутствие валидации входных данных (Map<String, Object>)
Почему это ошибка: Map не имеет схемы. Нет аннотаций @NotNull, @DecimalMin, @Pattern. Контроллер принимает любые поля без проверки. Что произойдёт в проде: NullPointerException при отсутствии полей, ClassCastException при некорректных типах, возможность инъекций через поля, отсутствие контроля лимитов и формата счетов. Исправление: Ввести строго типизированный DTO с @Valid, валидаторами и проверкой обязательных полей.
4. Слишком широкая транзакция (@Transactional на create)
Почему это ошибка: Транзакция охватывает не только работу с БД, но и внешние синхронные вызовы (antifraud, kafka, notifications). Это классическое антипаттерн. Что произойдёт в проде: Долгое удержание соединений БД, исчерпание connection pool, блокировки строк, таймауты на уровне DBA, деградация всей системы при зависании внешних сервисов. Исправление: Вынести repo.save() в отдельный метод с короткой транзакцией. Внешние вызовы выполнять асинхронно или через Outbox-паттерн.
5. Self-invocation и игнорирование @Transactional
Почему это ошибка: this.sendNotification(p) вызывается внутри того же класса. Spring AOP работает через прокси, и прямой вызов this. минует прокси. Аннотация @Transactional(propagation = REQUIRES_NEW) не применится. Что произойдёт в проде: Уведомление выполнится в той же транзакции, что и create. При откате основной транзакции уведомление не дойдёт. При успешном коммите, но падении notifications.send(), транзакция откатится, хотя логика могла предполагать отдельную обработку. Исправление: Вынести sendNotification в отдельный Spring-бин или использовать @Lazy self-injection.
6. Отправка p.toString() в Kafka
Почему это ошибка: toString() не гарантирует сериализацию, зависит от реализации, не является схемой и не поддерживает эволюцию формата. Что произойдёт в проде: Потребители получат невалидные данные, рассинхронизация downstream-систем, невозможность откатить изменения формата, ошибки парсинга в продакшене. Исправление: Использовать JSON-сериализацию (Jackson) с описанной схемой (JSON Schema / Avro / Protobuf). Формат должен быть версионирован.
7. Игнорирование ошибок отправки в Kafka
Почему это ошибка: KafkaTemplate.send() по умолчанию асинхронный. Возвращаемый ListenableFuture не обрабатывается. Ошибки сетевых сбоев или недоступности брокера просто логируются и игнорируются. Что произойдёт в проде: Платёж сохраняется в БД, но событие не доходит до Kafka. Потеря данных для аудит-систем, аналитики и downstream-сервисов. “Тихий” отказ. Исправление: Обрабатывать Callback с логированием ошибок и повторной отправкой, либо настраивать retries/acks=all на уровне KafkaTemplate. В критичных системах использовать Outbox.
8. Синхронный вызов antifraud без resilience-механизмов
Почему это ошибка: Нет таймаутов, circuit breaker, retry policy. Вызов блокирует поток в рамках транзакции. Что произойдёт в проде: При зависании антифрода — утечка потоков, исчерпание thread pool, cascading failure, таймауты на уровне Nginx/Gateway, недоступность всего API. Исправление: Добавить Resilience4j (@CircuitBreaker, @Timeout), настроить feign/webClient с таймаутами. Рассмотреть асинхронную проверку с последующим обновлением статуса.
9. Логирование через System.out.println
Почему это ошибка: System.out не интегрируется с ELK/Grafana/Sentry, не имеет уровней логирования, не структурирован. Что произойдёт в проде: Невозможность мониторинга и алертинга, засорение stdout контейнера, потеря информации при ротации логов, невозможность фильтрации по уровням. Исправление: Использовать SLF4J Logger с уровнями INFO/WARN/ERROR. Выносить в отдельный сервис логирования или использовать MDC для трассировки.
10. Перехват Exception и возврат e.getMessage() клиенту
Почему это ошибка: e.printStackTrace() не подходит для прода. e.getMessage() может содержать стектрейс, внутренние пути, названия таблиц, SQL-запросы. Что произойдёт в проде: Утечка внутренней информации (OWASP Top 10), плохой UX, невозможность корректной обработки ошибок на клиенте, засорение логов. Исправление: Использовать @ControllerAdvice + @ExceptionHandler. Возвращать стандартизированные ответы (ErrorDTO). Логировать детали на сервере.
11. Отсутствие обработки частичных отказов (Payment saved, Kafka failed)
Почему это ошибка: Если repo.save() прошёл, а kafka.send() упал — состояние рассинхронизировано. Транзакция коммитится, но событие не опубликовано. Что произойдёт в проде: Платёж в БД есть, но downstream-системы о нём не знают. Потеря данных для аудит-логов, аналитики, уведомлений. Восстановление требует ручного вмешательства. Исправление: Паттерн Outbox: сохранять событие в таблицу outbox в той же транзакции. Отдельный процесс (CDC или периодический опрос) доставляет события в Kafka с гарантией at-least-once.
12. Жёстко заданный статус "PENDING" (String)
Почему это ошибка: Использование строковых констант вместо enum prone to typos, не обеспечивает валидацию состояний, усложняет поддержку. Что произойдёт в проде: Ошибки при сравнении статусов, невозможность добавить новые статусы без рефакторинга всех сравнений, рассинхронизация состояний. Исправление: Использовать enum PaymentStatus с методами валидации переходов.
13. Генерация ID в контроллере
Почему это ошибка: Нарушение SRP. Контроллер знает о внутреннем устройстве сущности и механизмах генерации идентификаторов. Что произойдёт в проде: Сложности с миграцией на другие ID-генераторы, дублирование логики, невозможность переиспользовать сущность вне контекста REST. Исправление: Перенести генерацию ID в сервис или настроить @Id генерацию в JPA/Hibernate (GenerationType.UUID).
14. Возврат сущности Payment напрямую в ответе
Почему это ошибка: Сущность может содержать чувствительные данные, внутренние поля, циклические ссылки, которые не должны попадать в ответ. Что произойдёт в проде: Утечка данных, нарушение инкапсуляции, проблемы сериализации (StackOverflowError при циклических ссылках), привязка API к структуре БД. Исправление: Использовать DTO/VO для ответа. Маппинг через MapStruct или вручную.
15. Отсутствие идемпотентности и проверки на дубликаты
Почему это ошибка: Нет idempotency-key, нет проверки уникальности запроса. Клиент может повторить запрос при таймауте. Что произойдёт в проде: Двойное списание/зачисление, рассинхронизация балансов, финансовые потери, невозможность восстановить состояние после сбоя. Исправление: Добавить заголовок Idempotency-Key, проверять его в БД/Redis, возвращать предыдущий результат при дубликате.
ИТОГО: найдено 15 проблем.
Краткая сводка по категориям:
🔴 Транзакции: 4, 5
🔴 Интеграция: 6, 7, 8, 11
🔴 Безопасность/Данные: 2, 3, 10, 14, 15
🔴 Эксплуатация в проде: 1, 9, 12, 13
🟡 Скрытые под нагрузкой: 1, 4, 8, 15
Код требует рефакторинга с переходом на событийную архитектуру (Outbox), внедрением DTO, валидацией, resilience-механизмами и proper error handling.
===
● llama-server.service - Local LLM Server Loaded: loaded (/etc/systemd/system/llama-server.service; enabled; preset: enabled) Active: active (running) since Mon 2026-08-10 10:12:07 +03; 14min ago Invocation: e39cac952b104038baa54931c517f066 Main PID: 13278 (llama-server) Tasks: 16 (limit: 38021) Memory: 1G (peak: 1G) CPU: 1min 33.003s CGroup: /system.slice/llama-server.service └─13278 /usr/bin/llama-server -m /srv/models/Salience-1.5-Pro.Q4_K_S/Salience-1.5-Pro.Q4_K_S.gguf -t 8 -c 32768 -b 768 -ngl 99 --host 0.0.0.0 --port 8080 --parallel 1 --tensor-split 12,12 --temp 0.15 --top-p 0.92 --top-k 50 --min-p 0.05 --repeat-penalty 1.0 -ctk q8_0 -ctv q8_0 -fa on
авг 10 10:16:39 rtx run-llama.sh[13278]: 4.31.299.106 I slot print_timing: id 0 | task 2 | prompt eval time = 1700.81 ms / 607 tokens ( 2.80 ms per token, 356.89 tokens per second) авг 10 10:16:39 rtx run-llama.sh[13278]: 4.31.299.112 I slot print_timing: id 0 | task 2 | eval time = 85718.53 ms / 7575 tokens ( 11.32 ms per token, 88.37 tokens per second) авг 10 10:16:39 rtx run-llama.sh[13278]: 4.31.299.113 I slot print_timing: id 0 | task 2 | total time = 87419.34 ms / 8182 tokens авг 10 10:16:39 rtx run-llama.sh[13278]: 4.31.299.114 I slot print_timing: id 0 | task 2 | graphs reused = 7545 авг 10 10:16:39 rtx run-llama.sh[13278]: 4.31.299.178 I slot release: id 0 | task 2 | stop processing: n_tokens = 8181, truncated = 0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Этот код на Spring дают на java-собесе в ТБанке и Альфе. Найдёте все 8 багов за 15 минут?