«Время разработки фичи сократилось с 20 до 5 дней, число ошибок в коде — в два раза». Белорусские компании и программисты — о переходе с Java на Kotlin

33 комментария
«Время разработки фичи сократилось с 20 до 5 дней, число ошибок в коде — в два раза». Белорусские компании и программисты — о переходе с Java на Kotlin

Год назад языку Kotlin пророчили, что к концу 2018-го он станет популярнее Java в разработке приложений для Android. Новость о первенстве Kotlin как о свершившемся факте пока не прозвучала, но ещё и год не окончился. Между тем, всё больше белорусских ИТ-компаний переходят на новый язык. Некоторые, правда, не очень успешно: dev.by известно об одной компании, которой пришлось свернуть эксперимент. Мы собрали мнения разработчиков, попробовавших продукт компании JetBrains. Идеального разделения на Pro&Сontra не получилось, но поводы для дискуссии есть.

«Java останется с нами, но фокус сместится на Kotlin»

Руслан Ибрагимов, лидер белорусского Kotlin User Group:

Многие белорусские компании сейчас заявляют о том, что они используют Kotlin в разработке. Это Juno, Flo, Apalon, cyber•Congress, Id Finance, exp(capital), Яндекс, Itransition, Gismart и другие. В большинстве своём это, конечно, Android проекты, но некоторые из этих компаний используют Kotlin и на бэкенде.

Про Kotlin/Android

Массовый переход на Kotlin на Android-проектах начался, очевидно, в мае 2017 года, когда Google на конференции Google I/O заявила об официальной поддержке Kotlin на Android. Нужно понимать, что это было движение снизу вверх, то есть сначала множество разработчиков оценило удобство разработки на Kotlin под Android, а потом уже Google, увидев в Kotlin реальную альтернативу Java для платформы, сделала его официальным языком. Многие компании использовали Kotlin под Android ещё до Google I/O, а сейчас проще пересчитать проекты, которые не собираются переходить на Kotlin.

Вообще вся эта история напоминает то, как Google анонсировал Android Studio: официально говорилось что будет поддерживаться и старая IDE, основанная на Eclipse, и новая Android Studio, основанная на Intellij Idea CE. Но по факту, конечно, от поддержки Eclipse они отказались. Очевидно, такая же судьба ждёт и Java. Java останется с нами, но фокус Google наверняка сместится с Java на Kotlin.

Про Kotlin/JVM

Если на Android Kotlin уже победил, то на Server Side не всё так однозначно. Хотя Java и начала делать релизы чаще, но фич, которые значительно повышают продуктивность Java разработчика и качество его кода, становится всё меньше с каждым релизом. Так, в JDK 11 фактически не было достойных внимания фич. В то же время Kotlin, хотя и является инкрементальным улучшением с точки зрения внедрения в проект, позволяет значительно повысить качество, читаемость кода и искоренить в проекте некоторые типы ошибок.

Несмотря на это, в массе своей бэкенд разработчики не спешат переходить на Kotlin. С одной стороны, в этом может быть виноват менеджмент, который видит риск в новом языке. Наверняка они уже проходили историю с ещё одним JVM языком в проект и не верят, что Kotlin в этом плане значительно отличается от Scala, Groovy или Clojure. С другой стороны, есть разработчики, которых устраивает текущий порядок вещей, и они не хотят учить новый язык.

Радует, что множество крупных проектов обратили внимание на Kotlin и поддерживают его или используют для того, чтобы сделать лучшие инструменты для разработчиков. Так, можно выделить Spring Framework, развиваемый Pivotal, и систему сборки Gradle. Spring уже давно заявили о поддержке Kotlin, а сейчас даже разрабатывают экспериментальный микрофреймворк spring-fu на Kotlin. Gradle тоже использует на всю мощь Kotlin в проекте Gradle Kotlin DSL, который позволяет писать билд-скрипты на Kotlin. В результате разработчик получает все прелести статически типизированного языка как автодополнения, проверку корректности скрипта, документацию — всё то, чего не было при использовании Groovy.

Кстати, если вы хотите больше узнать о spring-fu, то приходите на jfuture.by, там будет доклад от создателя этого фреймворка.

Про сообщество

Целью сообщества Belarus Kotlin User Group является популяризация языка Kotlin и помощь разработчикам.

Можно сказать, сообщество отделилось от Java Professionals By, и до сих пор ядра сообществ очень сильно пересекаются. Первый митап мы провели буквально через месяц после релиза Kotlin 1.0. (Хотя о Kotlin я рассказывал ещё на митапе Java Professionals By, который состоялся через день после первого релиза). Кажется, это была первая Kotlin User Group в мире, сейчас же подобных сообществ насчитывается больше 160-и.

За всё время мы провели 10 митапов и не собираемся на этом останавливаться. Разные компании обращаются к нам за консультацией: например, просят прийти к ним и рассказать о Kotlin.

4-5 октября пройдет KotlinConf — главная конференция для разработчиков на Kotlin. И в этом году для всех будет доступна трансляция первого потока. В свою очередь, BKUG организует просмотр трансляции в SPACE.

«Сократилось время разработки и количество ошибок»

В компании Flo начали переводить Android-разработку c Java на Kotlin в январе 2018 года. СТО компании Роман Бугаев и разработчик, сооснователь сообществ GDG Minsk и Android Academy Павел Щегельский рассказали, как это было.

Павел Щегельский о мотивах

— Почему приняли такое решение? Во-первых, Kotlin даёт нам скорость разработки. Как правило, фичу надо было написать ещё вчера, и то, что 10 строчек можно заменить одной, сильно упрощает жизнь бизнеса.

Во-вторых, наш код становится более безопасным. Теперь мы понимаем, где и как можно использовать ту или иную переменную и какого типа она будет. Это была одна из проблем в Android-фреймворке на Java: ты не всегда понимал, стоит ли обрабатывать ошибку. Например, можно ли передавать nullable тип в функцию, будет ли возвращаемый тип nullable. Если в комментариях к методу нет чёткого описания, то ты не всегда уверен, вернёт он безопасное значение или нет.

Kotlin даёт явную возможность это указать, понимание кода значительно упрощается. И сейчас Android команда стала уже в Java коде обставлять эти случаи аннотациями, то есть Kotlin положительно повлиял на фреймворк Java.

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

А ещё Kotlin и Java могут работать вместе: какая-нибудь штука в Kotlin легко интерпретируется на уровне Java. Конечно, иногда привносится overhead, поэтому к некоторым механизмам надо подходить с умом. Это основной минус. Других явных минусов за два года использования Kotlin я не нахожу. Плюсов гораздо больше.

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

Сейчас в нашей компании открыто много вакансий, и тот факт, что наша разработка Kotlin based, мы стараемся обязательно упоминать. Это даёт преимущество компании в глазах кандидата. Если компания инвестировала в Kotlin, это значит, что она следит за тенденциями, использует современные инструменты и ценит комфорт разработчика. А кроме того, поработав у нас, разработчик сможет добавить хороший пунктик в резюме: для Android-программиста не знать Kotlin в 2018 году — это очень плохо.

Google настолько активно популяризирует Kotlin как официальный язык разработки под Android, что на рынке скоро будет больше разработчиков на Kotlin, чем на Java. И если какая-нибудь компания будет продолжать вкладываться в Java, то скоро она не сможет найти себе разработчиков.

Роман Бугаев о результатах

— Пока на Kotlin у нас только Android-разработка. Да ещё команда QA используют Kotlin для написания функциональных тестов для сервера и Android. Была идея также писать на Kotlin серверные решения, но мы от неё отказались: по сути, серверных разработчиков, владеющих Kotlin, не так много. Если же говорить про Android-разработчиков, то сейчас уже сложно найти программистов, готовых идти на проект с языком Java вместо Kotlin.

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

И по количеству фичей в производстве, и по времени на их разработку в компании Flo серьёзный прогресс. Не уверен, что это связано только с переходом на Kotlin (одновременно у нас менялась архитектура, в компанию пришли более сильные программисты), но среднее время разработки одной фичи сократилось с 20 до 5 дней.

Кроме того, за последние 90 дней число ошибок (non-fatal exceptions) в коде сократилось в два раза. Если раньше у всех пользователей суммарно было 9 млн событий в день, то сейчас — 3,6 млн. Несмотря на столь большие цифры, приложение у нас качественное: признаком этого является рейтинг в Google Play — 4,9.

При этом надо понимать, что за эти 9 месяцев мы перевели на Kotlin только 35% кода Android-разработки приложения, который писали более 2 лет. Но у нас и нет цели переписать весь код на Kotlin. У нас прагматичный подход: если мы работаем над какой-то фичей, которая затрагивает код, то мы его переводим на Kotlin. Если мы этот функционал не трогаем, то так на Java и живём.

И всё же процент перехода — довольно большой. Это связано с тем, что компания-создатель языка JetBrain сделала переход на Kotlin очень лёгким, частично он делается автоматически. Берётся Java-код, конвертируется в Kotlin, а дальше разработчик смотрит результат и добавляет пропущенные элементы.

О том, почему только Android

— Основной сдерживающий фактор использования Kotlin за пределами Android-разработки — это количество разработчиков. Kotlin — один из языков программирования в JVM мире (Java Virtual Machine), которые компилируются в Java-код, но не единственный. Если сравнивать Kotlin  с другими языками семейства JVM, например, Groovy и Scala, то на них гораздо больше программистов. Наши бэкенд-разработчики предпочитают использовать язык Scala, в котором, как и в Kotlin, делается упор на функциональное программирование. У него те же преимущества, что и у Kotlin, плюс большое число разработчиков.

Кроме того, компаний, которые пишут бэкенд на Scala, намного больше. Это и Twitter, и LinkedIn, и Uber. Поэтому на Scala есть фреймворки, которые оптимизированы под бекэнд-разработку.

Будут крупные разработчики — появится и инфраструктура, позволяющая писать бекэнд на Kotlin. Пока этого нет, и нужны сильные вендоры, которые будут вести этот рынок.

Ещё мы с интересом следим за кроссплатформенной разработкой для Kotlin. Если у них получится, это окажет большое влияние на рост популярности языка. Если на Kotlin можно будет делать разработки и под iOS, и под Android, и бекэнд, это будет означать, что один и тот же программист сможет делать фичу от А до Я, один человек заменит троих.

Правда, это похоже на создание «серебряной пули», не знаю, насколько это реалистично.

«Навигация отваливается, и скрипт краснеет»

Александр Росолько, разработчик в компании Tispr, на Kotlin пишет  «домашние» проекты, делает вклад в  open source. Участвует в разработке библиотеки Selenide (один из новых модулей будет написан полностью на Kotlin) на GitHub.

— К Kotlin отношусь нейтрально: как и во всяком языке, в нём есть и плюсы, и минусы.

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

Так как язык появился относительно недавно, одной из больших проблем является недостаточно большое комьюнити.

Отсюда вытекает и вторая проблема — недостаточное количество ресурсов для обучения.

На данный момент количество библиотек, написанных и работающих с Kotlin, невелико, причём львиная доля их заточена под Android-проекты.

Из этого вытекает следующий минус: почему-то Kotlin многие считают созданным именно под Android, поэтому другие проекты на нём даже не пробуют писать. Хотя на деле Kotlin позволяет делать всё то же, что и с Java, и даже немного больше.

Также досадным является тот факт, что скорость компиляции кода на Kotlin медленнее в сравнении с той же Java.

Следующая большая проблема Kotlin — это интеграция с текущими билд-системами.

Возьмём популярную билд-систему Gradle: изначально билд-скрипты использовали и используют на синтаксисе языка Groovy. Он так и называется — Groovy-скрипт. Он  работает быстро, однако у него довольно высокий порог вхождения, а без навигации по методам (конструкция) иногда непонятно, что происходит в том или ином месте, и как это вообще работает.

Потом нам представили Kotlin-скрипт. Он работает, и неплохо, но очень медленно.

Плюс к этому часто хвалёная навигация по скрипту «отваливается». И становится очень грустно, когда почти весь скрипт «краснеет», а подсказки редактора говорят вам, что «всё очень плохо». Решается эта проблема перезапуском среды разработки. Операция простая, но это не лучшее решение проблемы.

Если в вашем проекте на Groovy использовалась конфигурация с применением нескольких скрипт-файлов (которые в дальнейшем были использованы в основном), то с применением Kotlin-скрипта вы лишаетесь этой возможности. Так как использовать подскрипты в одном скрипте на Kotlin попросту невозможно, придётся все описать в одном основном скрипте, который может получиться очень большим. Надеюсь, что в дальнейшем такая возможность всё-таки появится.

«Пугает костыльность реализации»

Александр Бруй, Java разработчик в ITS Partner. Думаю, Kotlin наиболее актуален сейчас для Android-разработки из-за сильного отставания  «мобильной» Java от её «взрослой» версии. Перспективе писать код на старой Java 7 я предпочту использовать Kotlin.

Изначально Kotlin мне был интересен именно как «Java с модным синтаксисом», работающий на том же JVM, так как развитие синтаксиса у Java шло очень медленно. С выходом 8-й версии Java стал намного приятнее.

Учитывая, что развитие Java ускорилось с переходом на полугодовой релизный цикл, думаю, этот язык будет постепенно модернизироваться. При таком положении вещей смысл переходить на Kotlin есть только в тех случаях, когда нет желания/возможности постоянно мигрировать на свежую версию Java.  

JVM не единственная платформа для работы Kotlin, а значит, этот язык будет пытаться максимально абстрагироваться от специфики работы JVM на уровне синтаксиса, и мало ли к каким ограничением это приведет в будущем. Сейчас это хорошо видно на примере специфичных аннотаций для тех случаев, когда надо использовать эту специфику.

Kotlin старается быть совместимым сразу с несколькими мажорными версиями JVM, и это приводит к тому, что он не пользуется «новыми возможностями» более новых JVM. Хотя теоретически, конечно, может этому научиться.

Кроме этого, мне не нравится подход Kotlin в реализации каких-то сложных «фич» без поддержки их же на уровне платформы. К примеру, корутины. То, как это работает «под капотом», пугает меня «костыльностью» реализации: уж лучше я подожду Project Loom на Java, где это сделают максимально адекватно.

По теме
Все материалы по теме

Хотите сообщить важную новость?

Пишите в наш Телеграм

Читайте также

Резидент ПВТ купил хорватскую игровую студию
Резидент ПВТ купил хорватскую игровую студию

Резидент ПВТ купил хорватскую игровую студию

Qulix Systems и А1 внедрили IoT-решение для контроля безопасности мостов
Qulix Systems и А1 внедрили IoT-решение для контроля безопасности мостов

Qulix Systems и А1 внедрили IoT-решение для контроля безопасности мостов

Подразделение Mail.ru отдаст разработчикам игр 90% от дохода
Подразделение Mail.ru отдаст разработчикам игр 90% от дохода

Подразделение Mail.ru отдаст разработчикам игр 90% от дохода

«Поисковик» по блогерам стал продуктом месяца на Product Hunt
«Поисковик» по блогерам стал продуктом месяца на Product Hunt

«Поисковик» по блогерам стал продуктом месяца на Product Hunt

Обсуждение

6

>> одновременно у нас менялась архитектура, в компанию пришли более сильные программисты

Роман, куда пропали менее сильные программисты?

Anonymous
Anonymous
0

Куда, куда. Программистов счас много, особенно не сильных. Зачем они нужны, если можно взять ребят, которые начинали еще в 2010 и интересовались этим делом. Но я не Роман и не знаю что он с ними сделал.

Roman Bugaev
Roman Bugaev CTO в Flo Health
0

Программисты, которые были у истоков Flo по-прежнему с нами работают. Мы растем появляются новые вакансии. Сейчас у нас в 3 раза больше инженеров чем 9 месяцев назад.

0

"Ходят слухи, что Кирпич любит избавляться от людей с помощью электрошокера, пластикового мешка, липкой ленты и своры голодных свиней." ©

Anonymous
Anonymous
2

"Была идея также писать на Kotlin серверные решения, но мы от неё отказались: по сути, серверных разработчиков, владеющих Kotlin, не так много. "
----
Роман тоже рассматривает разработчиков как инструмент с табличкой навыков? Я не очень понимаю, в чем может быть проблема вдуплить джависту в котлин.

Roman Bugaev
Roman Bugaev CTO в Flo Health
0

Я имел ввиду community и иструменты конкртеной платформы/языка. Мы с радостью берем инженеров, которые не писали до этого на scala или kotlin к себе.

Anonymous
Anonymous
2

"Не уверен, что это связано только с переходом на Kotlin (одновременно у нас менялась архитектура, в компанию пришли более сильные программисты), но среднее время разработки одной фичи сократилось с 20 до 5 дней."
----
Интересно, как ребята дробят фичи, они же все разные, что они могут делать такую статистику. Ну и 5 дней это скрее срок для юзер стори а не для фичи. Хотя это ж Андроид разработка, как у них там фиг знает, мб там почти конвеер.

Roman Bugaev
Roman Bugaev CTO в Flo Health
-2

Мы отслеживаем rolling average по user story. При это мы стараемся следить за тем чтобы user story следовала модели INVEST (https://en.wikipedia.org/wiki/INVEST_(mnemonic)). Разработчики и PO договариваются по каждой user story во время вречи Backlog grooming.

3

"среднее время разработки одной фичи сократилось с 20 до 5 дней"

при переходе на что-то новое время разработки как правило увеличивается и количество багов растет, а потом через какое то время уменьшается.

да котлин неплох и мы его пользуем на бекенде, но что бы в 4 раза...

Anonymous
Anonymous
3

Тут почти всегда дело не в инструменте, а в самих фичах и в программистах.

2

Тоже терзают смутные сомнения, что синтаксис языка может увеличить в 4 раза производительность. Да и возможность заменить 1 строчкой 10 строчек кода - это на мой взгляд не главное, что позволяет ускорить разработку. Профессиональная команда аналитиков, менагеров и кодеров, другими словами правильная архитектура и настроенный рабочий процесс - это главное.
Ну и богатый, проверенный временем инструментарий еще.

1

У Котлина всё же не только синтаксис отличается (это вообще дело десятое), семантика куда важнее.

0

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

-2

Вам же даже пример про null safety привели в статье. Это именно семантики вопрос, и это не единственное отличие систем типов котлина и джавы. Груви, скала, кложа - тоже все на JVM, хотите сказать, что у них всех семантика одинаковая?

Roman Bugaev
Roman Bugaev CTO в Flo Health
0

Как я и написал:
>> Не уверен, что это связано только с переходом на Kotlin (одновременно у нас менялась архитектура, в компанию пришли более сильные программисты), но среднее время разработки одной фичи сократилось с 20 до 5 дней.

Нам повезло, что ребята, которые приходили уже знали kotlin и мы почти безболезненно начали его использовать.

6

а если бы на Delphi перешли, то до 1 дня сократилось бы ) + фонд зарплаты в 2 раза )

6

Как-то раз мы решили написать один из бекенд сервисов на Котлине. Пошли к менеджементу, тот говорит - не вопрос, идите к клиенту. Пошли к клиенту - там пожали плечами и попросили сделать презентацию. Мы сделали, расписали все прелести Котлина и подытожили их скромными 20% прироста производительности разработчиков по сравнению с джавой. Клиент посмотрел и сказал "нет". Потом выяснилось, что им не понравились наши 20%. Надо было в районе 3% остановиться. Ну, и на рынке не так много знатоков Котлина, а бизнес всегда стремится сделать из работников легко заменяемые винтики.

Пишу бекенды на Котлине больше года. Язык хороший, но прироста в скорости работы не ощущаю вообще никакой. Ни в 4 раза, ни в 2. Итоговый код компактнее джавового, но и только.

Gradle Kotlin DSL тоже использую довольно давно, но только недавно он начал приносить радость вместо отчаяния. Вернее, работа с ним в Идее с обещанными проверкой синтаксиса и автокомплитом. Хотя обновления грейдла все еще легко ломают скрипты с ничего не говорящими ошибками. И документации к Kotlin DSL по-прежнему нет. Есть только репа на гитхабе с примерами.

2

есть очень-очень детские ответы за Kotlin, но где именно пальцем тыкать не буду - тыкать пальцем неприлично

7

«Время разработки фичи сократилось с 20 до 5 дней, число ошибок в коде — в два раза» -- явно что-то нечисто. Котлин действительно чаще выглядит лаконичнее и кол-во кода меньше, но программисты же не пишущие машинки что бы ботллнек был в скорости написания :| Язык на том же рантайме что и Java с теми же интструментами и IDE - покажите мне чудо-либу на котлине, которая сократила вам так сильно время :O Ну и ошибки в коде тоже странно - Нуллпоинтеры что ли :D

1

Что за чушь в заголовке статьи?
Я про утверждение "Время разработки фичи сократилось с 20 до 5 дней, число ошибок в коде — в два раза"

Вы с переходом с ассемблера голого на котлин не получите таких результатов никогда!

Anonymous
Anonymous
0

Вы не позитивны, просто порадуйтесь за коллег.

0

а можно ли сделать сайт на ассемблере? лэндингпэйдж какой-нибудь

5

можно. описание https://m.habr.com/post/318916/ и сам сайт https://board.asm32.info код https://asm32.info/fossil/repo/asmbb/index и вывод автора:) Веб программирование на ассемблере возможно, не очень сложно, а результаты получаются весьма хорошие. В результате, такая работа весьма повышает общую культуру разработчика и позволяет ему получит глубокое понимание протоколов Интернет и как все работает на самом деле.

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

0

офигеть!

0

даже представить не могу сколько стоит поддержка сайта на асме и сроки решения проблем

0

https://m.habr.com/company/jugru/blog/318842/ :)

Да, абсолютно. Когда Kotlin станет мейнстрим-языком, значение компании JetBrains для рынка Software Engineering, на котором она работает, будет совершенно другим. То есть, про нас будут говорить, что мы не какие-то ребята, которые делают удобные, но в любой момент заменяемые инструменты, а как про тех, кто делает некоторую корневую фичу экосистемы, на которой всё строится. Это другой вес, другой информационный поток, и деньги, я думаю, тоже другие.

0

на js можно мобильные приложения писать, на нём же и back-end. Время разработки фичи сократиться до с 20 дней до 1дня. Смысл мучатся с компилируемыми языками, когда скриптовые сейчас так развиты.

0

на котлине можно писать веб, бекенд и мобильные приложения.
более того один и тот же код будет работать и там и там

0

> Смысл мучатся с компилируемыми языками, когда скриптовые сейчас так развиты.

Вы забиваете гвозди микроскопом? Я нет:) Под задачу и инструмент.

1

"... мне отделочники сказали, что после смены инструмента Makita на Bosch, ремонты выполняют в 3 раза быстрее".

Anonymous
Anonymous
-1

Хороший вброс.
Один самый важный вопрос остался вне поля зрения, так часто бывает, когда о предмете говорят фанаты.
Зачем весь это цирк нужен гуглу?

0

"Если на Kotlin можно будет делать разработки и под iOS, и под Android, и бекэнд, это будет означать, что один и тот же программист сможет делать фичу от А до Я, один человек заменит троих."
Как часто, до появления котлина, аднроид разработчики писали бэкенд на джаве, и наоборот?

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже