Технологический Центр Дойче Банка известен своими Java-спикерами: Руслан Черёмин и Алексей Рагозин давно выступают на конференциях, выбирая для докладов далеко не самые доступные темы, и оба ведут по техническому блогу. Дойче Банк поучаствовал в Joker 2016, и мы использовали это как повод задать Черёмину с Рагозиным по несколько вопросов.
Руслан Черёмин (senior developer)
— О вас обычно знают просто «он из Дойче» — а можете ли рассказать о том, чем именно там занимаетесь и как именно (например, какие инструменты используете)?
— Мы занимаемся валютным рынком. В частности, команда, в которой я работаю, занимается генерацией цен на валютные инструменты — мы собираем информацию со многих рынков, применяем к ней особую магию, и решаем, по какой цене сейчас готов торговать этой конкретной валютой со своими клиентами Дойче Банк.
Ничего сильно необычного из инструментов у нас тут нет: у Дойче Банка лицензия на IDEA, хотя некоторые специалисты ещё по привычке разрабатывают в Eclipse. Для сборки используем Maven и Ant, соседние команды используют Gradle.
— В «Без слайдов» вы говорили «оказалось, что Дойче Банку как раз был нужен такой специалист, как я» — а что именно означало «такой, как вы», в чём именно было соответствие роли?
— В тот момент моя нынешняя команда собиралась переписывать с нуля сервер генерации цен — с Disruptor, и прочими фокусами. У них была вакансия для человека, который будет основным разработчиком этого нового сервера, и добьётся с его помощью новых красивых цифр latency. А тут я с докладом про Disruptor, и как раз собираюсь уходить из Яндекса, и очень интересуюсь возможностью поработать в домене low latency. В процессе подготовки к конференции мы познакомились с Володей Долженко, через которого я, в итоге, оказался в Дойче.
— Расскажите для тех, кто далёк от банковского сектора: в чём специфика Java-разработки в таком месте, как ТехЦентр Дойче Банка, отличающая её от Java-разработки в целом? Повышенные требования к надёжности?
— Конечно, требования к надёжности у нас, конечно, выше, чем в среднем энтерпрайзе, но все-таки мы не шаттлы тут запускаем — чего-то заоблачного нет. Надёжность, в основном, обеспечивается избыточностью: например, из двух десятков источников данных, которые слушает наш сервер, только штук пять реально используются в каждый конкретный момент — очевидно, самые качественные. Остальные просто в обойме на замену, если вдруг качественный источник замолчит — у нас есть менее качественный, но все же рабочий. И такая избыточность на многих уровнях.
Особенность банковского сектора — то, что он очень регулируемый и проверяемый. Поэтому немалая часть бизнес-требований состоит в том, чтобы соответствовать запросам аудиторов. Например: мы сохраняем массу информации о том, что в наших системах происходит, и храним её чуть ли не вечно. Например: заметная часть требований к надёжности происходит не непосредственно от нашего бизнеса, а исходит изначально от аудиторов/регуляторов (иногда эти требования довольно странно выглядят в контексте конкретного приложения).
— На JPoint 2016 вы рассказывали про escape analysis — а можете ли привести из опыта работы какой-либо конкретный пример того, как его знание помогало справиться с конкретной рабочей задачей?
— Нет, не могу :) Это довольно свежее исследование, и какого-то заметного применения в моей работе ему пока не нашлось. Наши самые критичные в отношении производительности приложения были написаны еще во времена довольно старых версий Java, и там применены гораздо более дубовые методы оптимизации. А переписывать прямолинейное и надёжное на модное и молодёжное только потому, что оно модное и молодёжное… Я жду новых проектов — возможно, там это пригодится больше.
— Хорошо, это слишком свежее — а в случае с темами вроде Java Memory Model, о которой делали доклад в 2013-м, конкретные случаи «вот здесь это помогло» есть?
— Да, те же самые weak caches у нас в коде много где используются и помогают уменьшить нагрузку на GC. В горячих местах у нас есть специализированные под конкретный сценарий concurrent map-ы или буфера.
Вообще, знание JMM — это вспомогательный навык, основное применение для него — это отфильтровывать заведомо некорректные решения. В большинстве случаев я ищу решение, подходящее по функциональности, дизайну, производительности, — а модель памяти выступает как фильтр, отбраковывающий идеи, сложно реализуемые в многопоточных условиях, и наоборот, подсказывающий проверенные многопоточные паттерны.
Таких трюков, как с benign race, совсем немного. Большая часть практического применения JMM состоит в том, чтобы не делать глупостей и быть проще.
Алексей Рагозин (solution architect)
— Вы довольно «хардкорный» специалист. Дойче Банк подходит вам тем, что там много подходящих задач?
— По его меркам на «хардкорность» я не тяну. В RTC есть команды, которые решают задачи из разряда ultra low latency, вот там «хардкор». Но Дойче действительно привлекает меня тем, что очень часто приходится решать задачи, которые ещё не имеют «типовых» решений в индустрии. Я бы сказал, что если вам интересно заниматься определёнными технологиями (например, in-memory data grid), ТехЦентр Дойче Банка — это чуть ли не единственное место.
— У вас довольно активная публичная деятельность: многократно выступали на конференциях, ведёте англоязычный блог. В чём ваша главная мотивация для этого?
— Помимо блога и конференций, я длительное время преподавал на курсах второго высшего образования в МГТУ им. Баумана, а сейчас веду два курса в Java-школе нашего технологического центра.
Но возвращаясь к вопросу, основная цель — это расширение круга общения, обмен мнениями. Выступления и статьи в блоге вызывают отклик от читателей/cлушателей, очень часто я узнаю что-то новое.
— Про Java-школу любопытно: а какие два курса?
— Один о профилировании Java-приложений, другой о сборке мусора. Перекликается с двумя моими докладами на JPoint.
— Порой считается, что самообразования достаточно: мол, на StackOverflow уже любой ответ найти можно. А зачем Java-школа — что она даёт, чего в гугле не получишь?
— Школа даёт очень много. Грубо говоря, до тех пор, пока человек не понимает проблему, он не может корректно задать вопрос. А соответственно, не может найти ответ на StackOverflow. Это замкнутый круг. Поэтому многие инженерные задачи требуют некоторой «академической» базы, прежде чем человек сможет самостоятельно искать решение конкретной проблемы, используя общедоступные ресурсы. И это справедливо не только для узких технических тем вроде тюнинга JVM, а для очень разных. Никакой StackOverflow не научит правильно использовать сложный фреймворк или проектировать архитектуру приложения.
Напоследок — доклады, которые Черёмин и Рагозин делали в последние годы на конференциях JUG.ru Group:
Автор: JUG.ru Group
