Летом этого года мы в *instinctools организовали и провели серию онлайн-дискуссий с разработчиками и экспертами в области IТ. В рамках проекта «Техпора» нам хотелось услышать разные точки зрения на события и проблемы, которые волнуют разработчиков. Одна из этих серий касалась проблем современной разработки на Java. Дискуссия оказалась настолько информативной, что мы решили собрать самые интересные моменты  и опубликовать их здесь, на «Хабре». 

В разговоре приняли участие Developer JetBrains Тагир Валеев, организатор конференции RigaDevDays, основатель латвийского JUG Дмитрий Буздин, Developer Advocate проекта GraalVM, OracleLabs Олег Шелаев и Java Developer *instinctools Денис Лешенюк. Сразу хотим сказать, что мы не задавали тон беседе и не ставили экспертов в какие-то рамки. Это был достаточно свободный разговор, который касался наиболее важных тем для разработчиков. Если вы хотите поделиться своим взглядом на обсуждаемые вопросы – пишите в комментариях.

«Почему переезд на более новую версию Java всегда вызывает столько вопросов?»       

Developer JetBrains Тагир Валеев: Недавно наша компания проводила опрос на тему, какую версию Java разработчики и заказчики используют чаще всего. Опрос проводился в начале 2021 года. Java 8 набрала 72%, Java 11 – 42%, а на третьем месте была на тот момент самая «свежая» версия – Java 15 с 14%. Получилось, что в момент выхода новой версии Java привлекает к себе интерес, который потом быстро затухает. И еще такой момент: если кто-то пользуется Java от Azul, то можно достаточно долго сидеть на промежуточных версиях.

Developer Advocate проекта GraalVM, OracleLabs Олег Шелаев:  Я читал статью Карла Мастранджело, который описывал свой опыт обновления приложений с Java 8 на Java 16 на Netflix. В статье был описан очень интересный феномен, почему никто в Netflix не решался на обновление Java в проектах. Причем было очевидно, что новая версия Java функционально лучше. Новые решения всегда лучше, ведь эти решения создает команда разработчиков – умные люди, которые двигают вперед продукт. Язык становится лучше, мощнее, удобнее. Казалось бы, нужно обновляться и все должны хотеть эти обновления. Но почему-то многие компании и проекты этого обновления не делают.

Мастранджело рассказывает в своей статье, как он пришел на Netflix и обновил Java. Он делал обновление постепенно. Сначала нашел одну библиотеку, которая не поддерживала прямолинейный upgrade, отправил pull request на GitHub, его приняли – и библиотека стала лучше работать на Java 11. Затем он пошел дальше: обновил еще одну библиотеку, потом еще одну и так далее.

И за достаточно короткий промежуток времени (несколько месяцев) он один перелопатил систему библиотек, которые использовались на проектах, и провел достаточно безболезненный upgrade. Почему он это сделал? Просто потому, что ему никто не сказал: ой, как сложно сделать upgrade на новую версию Java.

Получилось, что Карл не знал, что это сложно сделать и сделал. Как говорится, глаза боятся, а руки делают. Ты постепенно двигаешься в лучшую сторону, и все. Понятно, что есть компании и проекты, в которых конкретная версия Java – это функциональное требование. Это может быть требование проектов из экосистемы или требование компании, у которой собственные регуляции и оплаченная поддержка определенной версии. Но есть много проектов, которые «знают», что якобы очень сложно обновляться на Java 11, ведь в ней добавили var, убрали API и что-то сделали с reflection. Что сделали с reflection, никто не знает, но все боятся. Мне кажется, провести обновление достаточно легко, если ты берешь и делаешь это.

«Если вы проводите обновление, то нужно добиться, чтобы все зависимости поддерживали новую версию»  

Тагир Валеев: Если вы проводите обновление, то нужно добиться того, чтобы все зависимости поддерживали новую версию. Причем не только зависимости, но и сами библиотеки. Это может быть tooling, это могут быть maven plugin. Когда вышла Java 9, многие maven plugin просто «разломались». Причем их сломал не Jigsaw, а то, что изменился формат версии. Единичка в начале исчезла, было 1.8, а стало 9  – и парсерам «сносило крышу».

У вас мог быть статический анализатор на CI или что-то зависело от asm библиотеки, которую с каждой версии нужно бампать. Поднять транзитивную зависимость сложно. Сейчас с переходом на Java 11 не возникает таких страшных проблем. Практически все ваши зависимости, которые могли быть использованы, до 11 версии дотянулись. У JetBrains есть своя история, нам довольно сложно переходить на новую версию Java, так как у нас своя Java (IntelliJ IDEA и другие IDE на сборке JVM). И чтобы перейти нам на новую версию, следует провести очень большую работу.

«Я люблю фичи, когда в языке появляется что-то новое и приятное…» 

Тагир Валеев: Я люблю фичи, когда в языке появляется что-то новое и приятное. Если фича появляется, то мы в IDE занимаемся ее поддержкой. Конечно, очень круто использовать records, ведь это позволяет в локальном контексте делать в Java множественный возврат из методов. Например, мне нужно вернуть из метода два значения и в соседнем методе использовать их. Разработчики создают какие-то классы, типа «пара», или пишут в переменную, создают массив из двух элементов. Иными словами, многим приходят на ум совершенно ужасные решения, потому что объявить класс на два поля было сложно. А сейчас это одна строчка кода. Его можно объявить приватным классом, вернуть и использовать. Но еще из важных фич я хотел бы отметить все, что происходит со свичами, как их прокачивают начиная с Java 14. И records еще долго будут завоевывать свое место под солнцем, а вот миграции на новые свичи идут практически автоматически. Наше IDE умеет это замечательно делать, вы переходите на новую версию Java, она сама видит, что этот старый и некрасивый свич можно превратить в новый, и он становится гораздо компактнее и красивее. 

«Не надо в начале карьеры переживать, что вы не на последней Java...» 

Дмитрий Буздин: Не надо в начале карьеры переживать, что вы не на последней Java. Базовые принципы программирования похожи на всех языках и на всех версиях. Умение дебажить, писать автоматизированные тесты и структурировать код переносится с одного языка на другой достаточно просто. Сначала нужно научиться работать в команде, а дальше можно перейти на другой проект, где будет «хорошая Java». Ни для кого не секрет, что кадровый рынок в IТ на пике  «пузыря», поэтому поменять работу на более интересную не составляет труда. 

Java Developer *instinctools Денис Лешенюк: Тут другой вопрос: насколько для тебя будет полезно следить за новшествами, если ты работаешь на Java 8? Будут ли новые знания откладываться в голове или после первого сложного релиза на твоем проекте и эти знания просто «смоет».

Дмитрий Буздин: За всеми технологиями не уследить. Если ты Java-эксперт, то можешь следить за всеми новинками в языке. Но вот ты, например, прочитал про shenandoah или про какие-то «GC-вещи». Но на практике далеко не у всех будет возможность их «потрогать» или получить опыт сравнения разных алгоритмов GC. И тут возникает вопрос: а надо тебе это или нет? Ты либо идешь в продуктовую разработку, или занимаешься созданием инструментария и open JDK. Это совершенно разные направления, их вряд ли стоит сравнивать. В мире достаточно мало специалистов занято разработкой JVM. Это очень интересно и может быть пиком интеллектуальной карьеры, но, возможно, это не всем нужно. Для разработчика главное выбрать свой стек и технологии, а дальше достаточно читать release notes, ходить на ивенты, общаться. Найти работу, где будет достаточно возможности для развития, сегодня достаточно просто.

Тагир Валиев: Все знать невозможно, вокруг много чего происходит. Следить за всем новым просто нереально и не стоит пытаться. Вы всегда понимаете, что у вас есть специализация, вы заняты в конкретной области и в конкретном проекте. Вот в этой области забирайтесь настолько глубоко, насколько нужно для решения ваших задач. Копая вглубь, старайтесь смотреть широко. Попишите иногда на другом языке программирования, хотя бы на уровне «hello world». Я пишу на Java, но просматриваю, что нового выходит на C#. Я не пишу на C#, но мне интересно, потому что все, что появляется сегодня в C#, завтра может быть и в Java.

Поглядывайте вокруг себя, вы не сможете погрузиться во все глубоко, но вполне возможно, что вы прочитаете про другой язык, а через 2-3 года что-то подобное «завезут» в ваш. А если и не «завезут», то вы поймете, что новые знания изменили ваше мировоззрение и помогают решить задачу, с которой вы сейчас столкнулись. Не прекращайте учиться, пытайтесь узнавать что-то новое, это помогает держать мозг в тонусе, а вы будете работоспособными большее количество лет.

«Программная разработка – это всегда история про деньги» 

Дмитрий Буздин:  Программная разработка – это всегда история про деньги.  В облачных сервисах память – это один из самых дорогих ресурсов. Обычно CPU в проектах не используется «на полную», а вот память в Java-проектах часто выбирается полностью. Это происходит потому, что полный «фарш» Spring – это 200 мегабайт, если делать меньше, то получим ошибку. Это и является причиной, почему многие компании идут на Go. Они делают микросервис на Go, он занимает 50 Мб RAM, заказчик или разработчик считает, сколько ему это выйдет по деньгам, и моментально принимает решение. 

Исходя из микросервисной архитектуры, мы можем предположить, что в проекте будет, например, 20 микросервисов. Получается, что по 150 Мб оверхэда с каждого спринга, а нам нужно рассчитывать на три реплики, съедается несколько десятков гигабайт. И главный вопрос – почему? И тут люди начинают отказываться от Java, несмотря на другие преимущества.

«Если ИИ что-то и оптимизирует, то только overflow» 

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

Дмитрий Буздин: Если ИИ что-то и оптимизирует, то только поход в stackoverflow. Ты пишешь два кода. Первый – системный, который решается походом в stackoverflow. И здесь действительно можно получить какой-то прирост. Но тут еще получается и много копипаст-кода, который непонятно откуда притянут.

Скачок не может произойти из-за сути программирования. Программирование – это инструкции. И обучить ИИ программированию можно, если только мы в машинный интеллект «закачаем» знания о конкретной проблемной области. Сейчас ИИ может играть в Starcraft и находить баги, но писать код искусственный интеллект не может.  Ведь кто-то должен человеческие требования транслировать в какой-то язык программирования, будь это визуальный язык или язык жестов. Исключить из разработки ПО человека пока просто невозможно, ИИ может обеспечить только больший комфорт в программировании.

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

Олег Шелаев: Непонятно, как будет развиваться прогресс, но ИИ будет применяться в узкоспециализированных вещах. Например, можно будет с помощью ИИ просматривать код, чтобы указывать разработчику, например, куда установить курсор, чтобы прописать какой-то параметр. Такого, что придет заказчик и попросит создать робота, который будет покупать биткоины, когда они стоят мало, и продавать их, когда они дорожают, а ИИ сделает jar-файл, конечно, не будет. Работа разработчиков программного обеспечения, скорее всего, будет упрощаться по мере развития технологий ИИ. Скорее всего, будет так, как с переводчиками. Приложений для перевода много, но по факту сложный перевод или ответственные встречи проводят профессиональные переводчики, а не программы. Люди де-факто решают какие-то критические вопросы, по такому пути может развиваться и ИИ в программировании. Не исключено, что разработчики будут писать только тесты, а ИИ – код.

«Это приятно, что вы пишите всего 30% кода, а денег получаете за 100%» 

Тагир Валиев: Недавно вышел GitHub Copilot который можно пока использовать только по приглашению. Но в Twitter можно уже увидеть записи, в которых разработчики демонстрируют сумасшедшие вещи. Оказывается, достаточно написать только название метода, а GitHub Copilot по названию полностью «придумает» тебе его тело. Так что новое будущее программирования уже не за горами, и мы внутри своей команды серьезно обсуждали, что разработчикам придется перепрофилироваться. 

Не исключено, что GitHub Copilot будет писать за всех программы. С другой стороны, то, что мы сами попробовали, еще не настолько волшебно, чем те примеры, которые публикуются в Twitter. Если смотреть на то, что происходит в разработке IDE, то можно отметить множество инкрементальных вещей, и они мне нравятся. Недавно появилась возможность, например, написать в Java «list.m» и вам тут же предлагается вариант«.stream.map».

Я поставил эксперимент: взял стандартную задачу подсчета в текстовом файле наиболее частотно встречающихся слов и написал на Java с нуля. При этом я включил логирование, из IDE легко сделать keylogger, включив режим записи макроса. И получил показатели, где я вручную вводил символы, а где IDE мне подсказывало. Получилось, что IDE написало за меня 2/3 кода. Это приятно, что вы пишите всего 30% кода, а денег получаете за 100%. Но стоит отметить, что написание нового кода – это далеко не самая большая часть работы программиста. Часто программист занимается отладкой, рефакторингом, исследованием багов, написанием и чтением документации, какими-то архитектурными вещами. И в перечисленных задачах автоматизация хоть и существует, но двигается с разной скоростью. Так что есть еще очень много работы, которую нужно делать программисту. И в будущее я смотрю с оптимизмом, ведь автоматизироваться будет наиболее скучная часть работы, которую мы головой понимаем, как сделать, но руками нам лень этим заниматься. Компьютер с радостью сделает за нас скучную работу, а самая интересная часть задачи будет на программистах довольно долго.

Дмитрий Буздин: Во многих проектах есть большая польза от умения планирования функционала. И в чисто бизнес-проектах скорость создания кода напрямую влияет на продуктивность. «Джетбрейнс» – это технология, которая ускоряет программирование в разы, но ей еще нужно «учиться». Если вы не используете какие-то умные фишки автокомлишена, а пытаетесь руками писать код, то вам до senior еще далеко по продуктивности. Эту «штуку» нужно приоритетно осваивать. Что касается замены программистов на ИИ, то этого не произойдет. Я делал на эту тему научную работу, идея замены разработчика на машину витает с 1980 года. Но пока мы видим только технологии, которые ускоряют написание или генерацию кода.

Онлайн-дискуссия «Современная разработка на Java» – одна из серий дискуссий проекта «Техпора» компании *instinctools. 

Всю дискуссию «Современная разработка на Java» можно посмотреть на YouTube или послушать в подкасте проекта «Техпора».