company_banner

«Для сообщества критически важно установить стандарты»: Марчин Москала о Kotlin



    Пару лет назад было много блог-постов «смотрите, какой интересный язык Kotlin», где объяснялись основы. В 2019-м разжёвывать азы уже не требуется, зато теперь появляется публикация совсем другого формата. Марчин Москала, который уже не первый год учит людей этому языку, сейчас выпускает книгу «Effective Kotlin» — то есть уже не просто «как писать на Kotlin», а «как писать на Kotlin наилучшим образом».

    А скоро Марчин приедет к нам на Mobius с докладом. Поэтому мы поспрашивали его и про новую книгу, и про доклад, и про обучение людей Kotlin, и о происходящем в индустрии вокруг этого языка. И про то, чем различаются слова «effective» и «efficient».

    — Для начала расскажите, пожалуйста, немного о себе. Что вы делали до того, как стали обучать людей и создали Kt. Academy?

    — Я программировал с детства. Начал с Visual Basic, когда мне было 10, потому что хотел делать игры. Позже, во время обучения, я открыл для себя Android и посвятил себя Android-разработке. В следующие годы я работал для компаний вроде Samsung, Warta и mBank (как сотрудник Apreel), Docplanner и Gamekit. А также обнаружил Kotlin и влюбился. Я начал выступать с докладами о нём, писать статьи и книги. Вскоре компании начали обращаться ко мне за тренингами, и так появилась Kt. Academy.

    — У вас есть статус партнёра JetBrains, а что он означает? Каким требованиям для него нужно соответствовать? Часто ли вы общаетесь с сотрудниками JetBrains?

    — Главное требование — хорошо знать Kotlin и распространять знания о нём. Также нужно, чтобы человек был надёжным, и не лишним будет, если он известен.

    Я поддерживаю связь с некоторыми участниками команды Kotlin, а также с евангелистами, но сам не уверен, насколько это связано с партнёрским статусом. Главным образом, этот статус — способ JetBrains сообщить, что кто-то знает определённую технологию JetBrains, и сертификаты от этого человека представляют ценность.

    — Вы учите людей Kotlin, так что получаете много фидбэка и вопросов о нём от разных людей. Что они говорят и о чём спрашивают чаще всего?

    — Людям он очень нравится. Они особенно отмечают его лаконичность и то, что у них получается очень легко. А беспокоят их функции верхнего уровня и неявные получатели в лямбда-выражениях (implicit receivers). По-моему, с первым вариантом проблемы нет, а вот что насчёт второго… Думаю, люди переусердствуют в его использовании, и мы только начинаем осознавать масштаб проблемы.

    — А есть ли в Kotlin-коде разных людей какая-то самая распространённая ошибка или антипаттерн?

    — Я думаю, это как раз излишнее стремление спрятать получатель. Ну, знаете, всякие DSL внутри DSL, apply внутри apply… всё чаще и чаще получатель используют скрыто. Это здорово, когда пишешь код, но не когда его читаешь.

    — Изначально все приходили в Kotlin только из Java. А теперь приходится ли вам учить людей, которые вообще не знают Java, но хотят узнать Kotlin?

    — Да, я обучал немало разработчиков на JavaScript и Swift, команду скалистов и даже команду разработчиков на C, для которых Kotlin был громадным прыжком. Ещё со стороны Kotlin много думают о питонистах — надеюсь, они тоже присоединятся.

    — А порекомендуете ли вы в 2019-м учить Kotlin как первый язык? Или начинающим всё равно придётся сталкиваться и с Java, так что будет сложно?

    — Если человек хочет заниматься Android-разработкой — определённо порекомендую. Если бы у меня было больше времени, я бы написал книгу о современной Android-разработке, которая вообще не затрагивала истоки, а сразу предлагала новые подходы: Kotlin, AndroidX, Room, WorkManager, ConstraintLayout и MVVM с ViewBinding (а скоро и вовсе Jetpack Compose)… Мы можем отлично прожить без Java, Support Library, DatabaseHelper, AlarmManager.

    В бэкенде посложнее, но и там увлекательно с современными Kotlin-фреймворками вроде Ktor. Так что для обучающихся это тоже может быть интересным вариантом.

    — Разные языки по-разному оценивают в контексте обучения: Python в этом отношении часто хвалят, Java порой критикуют. А каково преподавать Kotlin по сравнению с Java?

    — С одной стороны, в Kotlin куда проще что-то сделать. Когда преподаёшь Kotlin, очень помогает возможность поместить много классов и функций в один файл.

    С другой стороны, у Kotlin больше фич, чем у Java, так что их изучение требует времени. Хотя в некоторой степени эти идиомы всё равно воплощают повторяющиеся паттерны из Java: например, data-классы, которые для новичка в Java будут непростыми, а в Kotlin тривиальными, достаточно добавить модификатор data. Я бы сказал, что в целом учить Kotlin веселее.

    — Порой Kotlin воспринимают только «языком для Android», но у него есть амбиции и в других сферах. Что вы видите по своим тренингам: весь спрос на них со стороны мобильных разработчиков, или бэкендеры тоже обращаются?

    — Год назад почти все были для Android-разработчиков. А сейчас, думаю, примерно 50 на 50. Также растёт интерес к тренингам «Kotlin Coroutines» и «Effective Kotlin».

    — К вопросу об «Effective Kotlin»: ваша новая книга называется так же, а ваш доклад на Mobius — «Efficient Kotlin». Означают ли такие похожие названия, что новый доклад — это краткий пересказ тезисов всей книги?

    — У слов «effective» и «efficient» в программировании очень разные значения, как у «safe» и «secure». «Effective» — более общее, про самые разные best practices. А «Efficient Kotlin» — это только о производительности и оптимизациях памяти, в книге этому посвящена третья часть. Для Mobius это лучше подходит, потому что конференция известна продвинутыми докладами для опытных разработчиков. А время доклада ограничено, всю книгу там не осветить.



    — А принципы из «Effective Kotlin» и «Efficient Kotlin» подходят всем разработчикам, что бы они на Kotlin ни писали, или там есть какая-то специфика?

    — Всем: не только Android и бэкенд, но даже тем, кто использует Kotlin/JS и Kotlin/Native.

    — Название «Effective Kotlin» немедленно заставляет вспомнить «Effective Java» Джошуа Блоха. Насколько ваша книга похожа на неё?

    — Есть много книг формата «Effective X», и все они построены по одному принципу: на конкретных примерах показывать, как лучше писать код. Я вдохновлялся и «Effective Java», и другими — «Effective C#», «Effective Python», «Effective C», «Effective JavaScript». Но нет какой-либо строгой привязки к любой из этих книг — всё это разные языки, и с ними требуются разные советы. Хотя если вы прочитаете их все, а потом прочитаете «Effective Kotlin», сможете увязать любой мой совет с советами из других «эффективных» книг. А также с советами из других влиятельных книг вроде «Code Complete», «Clean Code», «Clean Archutecture», «Structure and implementation of computer programs» и так далее. Моей целью было взять лучшие советы, которые подходят Kotlin, и презентовать их самым понятным образом.

    — Про Kotlin уже издано немало книг, но обычно они были в формате «как сделать что-то на Kotlin», а не «как сделать это самым эффективным образом». Считаете ли вы, что сначала сообществу были нужны основы Kotlin, а теперь оно освоилось и хочет повышать качество?

    — Да, я думаю, сообщество так разрослось, что теперь ему нужны best practices. По данным официального сайта, в мире уже больше двух миллионов Kotlin-разработчиков. Это очень много. Уже есть много статей формата «Как сделать...» и ответов на Stack Overflow, но есть всё больше людей, которым пришлось использовать Kotlin из-за решения CTO, или для которых он стал первым языком. Теперь задать стандарты критически важно, потому что Kotlin позволяет очень многое, и если мы не остановим людей от безумных вещей, в итоге его могут перестать любить и начать считать запутанным и нечитаемым.

    — Best practices — это всегда дискуссионная тема, мнения людей по поводу «как лучше всего» расходятся. На ваших тренингах или докладах возникают дискуссии?

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

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

    — Первую я опубликовал в Pact. Я оказался не вполне доволен сотрудничеством, так что я решил издать «Effective Kotlin» самостоятельно с помощью LeanPub. Пока что опыт отличный. У меня отличные ревьюеры-добровольцы, хороший дизайнер и славная типография. Проблемы возникли только с аккаунтом в Amazon, но надеюсь, успею разобраться с ним до публикации окончательной версии книги.

    — Советуете ли вы разработчикам писать книги? Насколько это полезно для разработчика?

    — Приступая к книге, надо знать, что это почти наверняка займёт больше времени, чем вы предполагаете. Прикидывайте по 1-2 часа на страницу. И если вы разработчик, маловероятно, что книга принесёт вам больше денег, чем если бы вы потратили это время на программирование. С другой стороны, вы многое узнаете. Чтобы уверенно писать, нужно тщательно изучить тему и по-настоящему понимать каждый довод. А это уникальный опыт.

    — И последний вопрос: если бы вы могли изменить в Kotlin одну вещь, что бы это было?

    — Думаю, я бы избавился от Unit. Он немного раздражающий. Особенно при взаимодействии с некоторыми другими языками.

    Напоследок напомним ссылки на упомянутое в тексте. Книга «Effective Kotlin» публикуется на Leanpub, а описание нового доклада Марчина, с которым он в декабре приедет на Mobius, опубликовано на сайте конференции (и там же можно посмотреть её полную программу).
    JUG Ru Group
    450,01
    Конференции для программистов и сочувствующих. 18+
    Поделиться публикацией

    Комментарии 16

      +1
      — И последний вопрос: если бы вы могли изменить в Kotlin одну вещь, что бы это было?

      — Думаю, я бы избавился от Unit. Он немного раздражающий. Особенно при взаимодействии с некоторыми другими языками.

      Сорри, не понял: что именно Марсину Москале так не нравиться в Unit и его интеграции с другими ЯП? Понимаю, если бы он про companion objects упомянул, но про Unit… И раз Unit плох, то что вместо него в таком случае?
        0
        Когда увижу его на Mobius, попрошу развернуть мысль)
          0
          Спасибо)
          0

          Unit плох тем что он не то же самое что void. Это заметно если вы в джаве, например, оверрайдите/имплементите котлинскую функцию, возвращающую Unit.

            0
            То есть его нужно на void заменить?
              0

              Нет, не нужно, т.к. не джавой единой

                0

                Так другим языкам в описанной мной конструкции тоже надо возвращать Unit.VALUE, разве нет?

              0

              Но имхо тогда уж void плох тем, что он не Unit.
              А то, например, есть интерфейс типа Callable<In, Out> и внезапно выясняется, что void в качестве типа не подставить, начинаются костыли с типами-заглушками (тот же Void).

                0

                Возможно, но void на момент создания котлина уже был.

            0

            А у Котлина есть своя экосистемы? Можно эффективно разрабатывать и разворачивать те же веб-приложения и сервисы, ничего не зная о Java? Или это как TypeScript: всё что есть "родного" только компилятор и плагины в IDE, даже пакетного менеджера нет и используются пакеты JavaScript, более того пакет на TypeScript публикуется в виде JavaScript пакета, в котором есть много JavaScript кода и немного определения типов TypeScript.

              0
              А у Котлина есть своя экосистемы?

              Kotlin native
                0

                Я не о нативной компиляции, я именно об экосистеме. Вот открыл первый попавшийся пример Kotlin native, а там половина корневой директории gradle-файлами занята. Или вот https://github.com/JetBrains/kotlin-native/blob/master/samples/html5Canvas/src/httpServerMain/kotlin/HttpServer.kt#L21 — импорт из java

                  +3
                  Если правильно понимаю, с экосистемой вкратце так: в Android-разработке всё уже цветёт и пахнет (и библиотеки сразу на Kotlin пишут, и в официальной документации примеры по умолчанию на Kotlin, и так далее), а в остальных направлениях пока что сложнее, но работа идёт и в JetBrains совершенно не хотят оставаться «джавовым тайпскриптом».
                0
                Я не думаю, что это хорошая идея — начинать писать проект на Kotlin не зная Java. Определённая экосистема есть, но в основном это обёртки вокруг Java-библиотек, а обёртки это дело такое, когда-нибудь придётся смотреть вниз.

                Впрочем Java в каком-то смысле это подмножество Kotlin, поэтому я не представляю, почему это может представлять проблему. Если человек знает Kotlin, в Java ему разобраться должно быть тривиально.
                  0

                  Ну вот в PHP очень многие библиотеки стандартные лишь обёртки над системными (читай сишными) либами и, думаю, 99,99% PHP программистов в лучшем случае об этом только догадываются, хотя и плюются от неконсистентности API, но никогда сишных исходников не открывали. Так что обёртка обёртке рознь.


                  Проблема скорее в оценке сроков первого проекта на Kotlin. Грубо говоря, объём документации по Kotlin — это одно число, а если к нему добавить Java — совсем другое.

                +2

                Рекомендую его доклад "Kotlin Not-to-Do List", много интересных вещей затрагивает. Отличный докладчик в целом.
                имхо: не Марсин, а Марчин правильно будет.

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

                Самое читаемое