Большой разговор о нескучной Java и жизни вне кода

Владимир Плизга

Ведущий бэкенд-инженер в Tibbo Systems. Занимается развитием AggreGate — интеграционной low-code-платформы для IoT. До этого 10 лет работал в финтехе над серверной частью интернет-банков и сопутствующих сервисов. Автор нескольких open-source-инструментов для тестировщиков и разработчиков. Докладчик конференций JUG.ru, CodeFest, IT Nights и других, автор статей по различным темам вокруг Java. Член программного комитета сибирской Java‑конференции SnowOne.

Содержание:

• Почему Java?
• Чем IT похожи на спорт
• Чего нам не хватает в столичных конференциях и почему мы решили сделать собственную
• Чем IT в финтехе отличаются от других
• Как поддерживать высокое качество кода
• Зачем нужны технические спринты
• Как администрировать микросервисы
• Как будет развиваться Java
• Что круче — Java, Kotlin, Scala или Groovy?

В IT я пришёл, наверное, классе в пятом: нашёл в закромах, оставшихся от дяди, старинный советский калькулятор Б3-34. В нём можно было программировать на языке, представляющем некое подобие ассемблера. Какие-нибудь примитивные программки для упрощения рутинных бухгалтерских задач или, например, для подсчёта кубического корня.

Потом у меня появился 486-й компьютер, я переполз на Turbo Basic, позже — на Pascal, ну и пошло-поехало. Приход в Java не был каким-то прямо осознанным. Мы, конечно, проходили её в университете, но тогда она не произвела на меня особого впечатления. А когда впервые всерьёз задумался о выборе работы — понял, что это востребованная область. Моих знаний на тот момент едва хватало, чтобы заступить на позицию джуниора. Тем не менее я смог пополнить команду молодых специалистов ЦФТ и начал её укреплять. Возможно, мой опыт пригодится кому-то ещё.

Почему Java?

В моей нынешней компании Java используется для интеграции и обработки данных с различных устройств.

Для подобных задач, возможно, подошёл бы и другой язык JVM-стека, но была выбрана именно Java, в основном за наличие большой, надёжной и динамичной «экосистемы» инструментов вокруг неё.

Чем IT похожи на спорт

Будучи и программистом, и спортсменом-любителем, я заметил между этими активностями нечто общее. Зайдём издалека. Полагаю, большинство разработчиков — не просто исполнители: «Мне дали задачку, я её пилю с девяти до шести, потом встаю, ухожу и забываю».

Разумеется, накопление подобных скиллов постепенно приводит к мысли, что знаниями нужно делиться — причём как с небольшой группой товарищей или коллег на митапе, так и с огромной аудиторией на конференции.

Со временем вырабатываются три совершенно разных режима работы. Первый — когда ты просто накапливаешь опыт: решаешь повседневные задачи, делаешь то же самое, что и большинство твоих коллег. Второй — ты осознаёшь, что твои знания и навыки могут быть полезны другим людям, и начинаешь агрегировать этот опыт, чтобы передать другим. Это требует иных навыков, подходов или даже мышления. Наконец, третий —кульминация процесса, когда ты пишешь статью, где-то выступаешь или как-то ещё участвуешь в публичной деятельности, делясь своим опытом с «братьями по оружию».

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

Мне наиболее близок пример циклических видов спорта: бег, плавание, велосипед, лыжные гонки и тому подобное. После череды тренировок наступает понимание, что прогресс есть, а потом — что его можно «опубликовать», то есть зафиксировать в виде рекорда или соревнования. Это во многом напоминает те же три режима работы, только в спорте.

Чего нам не хватает в столичных конференциях и почему мы решили сделать собственную

Любая конференция — это в первую очередь возможность погрузиться на какое-то время в атмосферу профессиональной движухи с максимальной концентрацией и отдачей.

Первой попыткой была посвящённая JVM секция в составе IT-фестиваля CodeFest, которую по части программы возглавлял Иван Углянский. Тогда удалось пригласить известных спикеров, в целом всё получилось, но мы были несколько сжаты тем форматом, который нам предлагали.

На следующий год, поняв, что потребность в хардкорных конференциях по-прежнему сохраняется, мы решились провести собственную. Назвали её SnowOne — по аналогии с JavaOne, проходившей прежде под эгидой Oracle. Мы успели аккурат перед началом ковидных ограничений. Для многих из наших спикеров это была последняя офлайн-конференция перед грядущим перерывом на полтора-два года.

Фишка SnowOne в том, что программный комитет состоит исключительно из практикующих разработчиков. Мы приглашаем только тех спикеров, на чьи выступления пошли бы сами.

Чем IT в финтехе отличаются от других

В финтехе, по сравнению с другими отраслями, во много раз больше внимания уделяют безопасности.

Второй, не менее важный, аспект — производительность. Финтех в первую очередь ассоциируется с трейдинговыми платформами, где сто тысяч миллионов транзакций в секунду и всё летает. Я работал над предоплаченными картами — в более спокойном секторе финтеха, где нагрузки были ниже, но требования к удобству — очень высоки. Тысячи людей приходят с деньгами и рассчитывают, что этими деньгами они смогут легко распоряжаться — видеть их, переводить, оплачивать всевозможные услуги. При этом вход в приложение должен быть максимально быстрым, чтобы пользователь мог открывать приложение или сайт на одном дыхании. Загрузка выписок и истории операций — другой огромный головняк для бэкенда, но пользователя, естественно, это волновать не должно.

В этом секторе пользователь априори не будет терпеть. Если ему что-то не нравится, он просто уйдёт. Поэтому приходится бороться, отстраивать какие-то мелочи, шлифовать фичи. Это проявляется не только во внешнем виде, дизайне или продуманности поведения, но и во многих внутренних компонентах.

В IoT все эти аспекты тоже важны, но приоритеты зачастую другие. Здесь важно обеспечить максимальную совместимость, покрытие всевозможных устройств, поддержку драйверов и их интеграцию с другими системами — ERP, MES и так далее.

Как поддерживать высокое качество кода

Я бы, наверное, начал с покрытия модульными тестами. Чтобы сделать его «честным», приходится прибегать к каким-то более изощрённым инструментам вроде мутационных тестов.

В прошлой команде мы постепенно пришли к этому инструменту, и он действительно указал нам на некоторые места, в которых мы сами себя обманывали. Несмотря на высокие показатели Java Code Coverage, по факту проверки в тестах были фиктивными.

Отдельная песня — статический анализ. Какими бы навороченными и опытными мы ни были, мы всё равно ошибаемся и на код-ревью надеяться не стоит. Поэтому я использовал SonarQube как один из этапов выпуска каждой фичи.

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

Зачем нужны технические спринты

Бывают крупные задачи — например, обновление Java сразу на несколько версий. Такие задачи между делом не втащишь: «продать» их заодно с другими бизнесовыми задачами в двухнедельный спринт — такое себе мероприятие.

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

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

Как администрировать микросервисы

Мы в своё время начали с первого приходящего в голову решения — с картинки. Это было нормальное решение — но только до тех пор, пока у нас не стало порядка 15 микросервисов и картинка почему-то перестала обновляться.

Сначала мы думали, что всё дело в нашей лени. А потом поняли, что, во-первых, её объективно стало тяжело обновлять, а во-вторых, она стала очень сложной и для тех, кто на неё смотрит. Требовалось другое решение.

И всё сразу зажило. В любой момент времени мы видели, сколько у нас микросервисов и как они выглядят, а также получали ответ на множество частных вопросов: где у нас используется SSL, а где нет, какие интеграции у нас построены на TCP, какие микросервисы ходят в базу и так далее. Даже обучение новичков стало проходить намного проще. Уже после моего ухода коллеги научились обновлять эту базу автоматически через аннотации в коде и сейчас успешно применяют этот инструмент в нескольких проектах.

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

Поэтому мы пошли другим путём и поначалу стали всей командой выбирать названия на основе так называемых производных ассоциаций. То есть брать основное понятие, которое у нас ассоциируется с новым микросервисом, и пытаться изложить его в виде существующих слов. Так получилась куча креативных названий. Более или менее на слуху, наверное, микросервис «Пушкин», который, как нетрудно догадаться, занимается пушами, или микросервис «Кварк» для QR-кодов.

Как будет развиваться Java

Начиная с десятой версии Oracle стал сильно вкладываться в фичу JVM, которая называется CDS/AppCDS (class data sharing / application class data sharing). Это, как мне кажется, очень интересная оптимизация, позволяющая расшаривать заранее верифицированные и распарсенные классы между разными инстансами виртуальной машины.

Идея в том, чтобы позволить машинам обойтись без верификации и парсинга, беря готовые данные, и не тратить ни процессорное время, ни память. Там куча своих сложностей, но в целом, я думаю, фича всё-таки жизнеспособная и найдёт себе применение — если не со Spring Boot (к которому я её примерял), то с другими фреймворками или библиотеками. Я знаю, что IntelliJ IDEA уже использует её «под капотом» для ускорения запуска.

Ещё одна фича — pattern matching, которая сильно упрощает кодирование. Повторяющиеся конструкции теперь можно писать гораздо быстрее и лаконичнее, а код при этом становится более читабельным.

И ещё мне не терпится начать использовать полноценные текстовые блоки. Они появились сравнительно недавно и сейчас уже полностью доступны. К сожалению, мне сильно не хватает интерполяции строк, которая есть в других языках. Например, в Kotlin, где она используется во весь рост.

Что круче — Java, Kotlin, Scala или Groovy?

Как старовер, я остаюсь на Java. Хотя, если мы говорим о продукте в «чистом поле», мне больше нравится Kotlin. Почему бы и нет — пишем меньше, получаем больше, всё красиво, круто, молодёжно, современно.

Если же речь идёт об уже состоявшемся продукте, я придерживаюсь более консервативной точки зрения и не тороплюсь устраивать «зоопарк». Даже ради крутых фич и компактности кода вносить новый язык в уже существующий продукт — на мой взгляд, сомнительная затея. Тут нужно многое взвесить.

И ещё один аргумент — совместимость языка с существующей экосистемой: составом фреймворков и библиотек, которые уже есть в продукте. Несмотря на разговоры о том, что Kotlin на 100% совместим — просто пиши всё то же самое и будет у тебя на Java работать, я знаю несколько довольно показательных примеров, где Kotlin показывает себя не с лучшей стороны. Особенно когда речь заходит о работе на Spring Boot. Это касается и работы с обнуляемыми объектами, и с механизмами проксирования, и с некоторыми другими фишками. Не окажется ли так, что время, сэкономленное на написании типичных геттеров и сеттеров, мы потом убьём на отлов безумных багов?

Ну а в целом у меня нет каких-то предустановленных принципов, по которым бы я строго выступал против одного языка или строго за другой. Предлагаю исходить из ситуации.