Как выступить на Mobius и внести свой вклад в Kotlin — Максим Сидоров (SberDevices)

Максим Сидоров, Android-разработчик из SberDevices, на весеннем Мобиус представил свой первый доклад “Измеряем sequence”, в котором разбирался с механизмом обработки коллекций в Kotlin. По результатам его доклада в Kotlin были внесены изменения, а я решил пообщаться с Максимом и поговорить про язык, карьеру, работу и многое другое. Это первая часть нашего интервью.

Как ты занялся Android-разработкой и Kotlin? 

До Android я довольно долго занимался разработкой больших ERP систем. Я 12 лет разрабатывал очень известную в России медицинскую систему Медиалог и вырос в этой компании до позиции технического директора.

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

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

В начале это было очень сложно, моя зарплата уменьшилась в 5-6 раз, а была еще ипотеĸа. Но я верил в собственные силы и достаточно быстро вырос до уровня сеньора. Со временем выросла и зарплата, но самое главное, что я отĸрыл для себя новый мир мобильной разработĸи и это ĸаĸ новая жизнь для разработчиĸа. Ты снова узнаешь нюансы, изучаешь технологии, отĸрываешь для себя новые фреймворĸи и языĸи. Ты ĸаĸ будто заново рождаешься, но при этом сохраняешь все свои предыдущие знания и опыт.

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

Нам приходилось убеждать и доĸазывать, что за языком будущее, что он генерирует безопасный и производительный ĸод. Чтобы убедить ĸомьюнити (на тот момент более 150 разработчиĸов), я занялся изучением того, ĸаĸ Kotlin работает под ĸапотом, ĸаĸ он генерирует свой байткод. По результатам этих исследований я провел целую серию внутренних митапов Сбера, где рассĸазывал и поĸазывал, ĸаĸ Kotlin работает изнутри. Поĸазывал что это безопасно, что это удобно и что это намного лучше Java.

Мои митапы были довольно популярны и за год я заработал неофициальный титул лучшего доĸладчиĸа в ĸомьюнити Сбербанка. В течение года нам удалось переломить ситуацию. Сначала нам удалось пробить разрешение на ограниченное использование Kotlin в проеĸте. И спустя год многие разработчиĸи Сбербанк Онлайн начали использовать в своей работе язык Kotlin. Спустя 2-3 года в Сбербанĸ Онлайн уже ниĸто не пишет на Java. За эту работу мне одному из первых было присвоено звание Dev Expert и Kotlin Expert.

Как так получилось, что за столько лет ты публично не выступал? 

Первые 25 лет своей карьеры я был классическим стартапером. Я сделал довольно много проектов и часть из них стали достаточно известными.

Возможно, в то время публичные выступления были для меня не важны. У меня были другие приоритеты. Мне хотелось создавать продукты, лучшие на рынке продукты. Я жил в ритме классического стартапа. Быстрее, быстрее, завтра релиз, послезавтра показ инвесторам.

Когда я пришел в Сбер, то с удивлением обнаружил, что есть и другой подход к разработке. В крупных компаниях он иной. Он более инженерный. Тут важнее качество, а не скорость.

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

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

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

На самом деле, последние три или четыре года я активно выступал на внутренних митапах. У меня был целый цикл докладов по тому, как Kotlin работает под капотом, про корутины, про interopp с Java.

Ну а в этом году я решил замахнуться на Мобиус) Возможно мной двигало тщеславие. Захотелось получить это достаточно почетное звание «спикер Мобиуса».

А посещал в принципе? Какая конференция тебе больше всего понравилась?

Да, конечно. Я много раз был на Мобиус и конечно для меня он стоит на первом месте. Это всегда событие и это особая атмосфера. Здесь ты не столько узнаешь что-то новое, сколько знакомишься с интересными людьми, проникаешься этой атмосферой.

Мобиус — это всегда немножко тусовка и шоу. Ты можешь подойти к разработчику VK и обсудить с ним нюансы реализации сложной верстки в их ленте. Какие-то совсем глубокие нюансы работы RecyclerView.

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

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

Мои фавориты — это Мобиус за атмосферу и особое ощущение шоу, и Android Academy за технический уровень докладов.

Какой твой любимый язык программирования?

Конечно же Kotlin. Когда он появился, я буквально влюбился в него. В нем было все, чего мне так не хватало в Java.

Но самое главное, у Kotlin потрясающе продуманный дизайн языка. Если сравнивать его с Java, то дизайн Java — это БДСМ, а дизайн Kotlin — это божья роса.

По Java видно, что они лепили фичи языка как придется.  Например, их статические классы, их класс Object с включенными в него методами синхронизации, отсутствие свойств, разделение ошибок на checked/unchecked. Примеры можно приводить бесконечно.

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

Как ты оцениваешь Kotlin и его развитие?

Мне кажется Kotlin уже успешно прошел активную фазу своего развития. Когда формировалась структура языка. Когда язык активно обрастал фичами.

Вообще, разработчики языка выбрали очень удачную форму для захвата рынка.

Они как кукушка — подкидывают свой код в гнездо других языков.

И это позволило им бесплатно получать кроссплатформенность Java и всю платформу Android. Получить портирование на бэкенд и Web. На мой взгляд именно это позволило им очень быстро захватить целые сегменты рынка. Kotlin распространялся как пожар.

Сейчас в это трудно поверить, но еще 4 года назад в Сбербанк Онлайн все было написано только на Java. Сейчас, спустя 4 года, весь код пишется только на Kotlin. Кода на Java в проекте уже практически не осталось. И сейчас уже все забыли, каково это, писать код на Java. А ведь прошло всего 4 года.

Сейчас Kotlin сосредоточился на захвате других сегментов рынка. На мой взгляд, основной упор делается на кросс-платформенность. И развитие идет именно в этом направлении.

Давай вернемся к докладу. Что такое Kotlin Sequences простыми словами?

Если простыми словами, то это ленивые коллекции.

С обычными коллекциями ты работаешь как с наборами данных. У набора есть начало и конец. Есть число элементов. С Sequences ты работаешь именно с последовательностью. Ты не знаешь, есть ли у нее конец, у тебя нет информации о числе элементов. Ты не можешь двигаться по ней вперед и назад.

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

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

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

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

Именно потому мне захотелось исправить это и подойти к этой проблеме с математической и инженерной точки зрения. Получить конкретные цифры и кейсы, в которых использование Sequences оправдано. Собственно так и родилось мое исследование и мой доклад.

Некоторые фунĸции Sequences работают не оптимально — что это значит? Как понять “обычному разработчику”, что функция языка работает не оптимально?

Наверное, тут нет четких критериев. Обычно ты узнаешь это, когда у тебя возникает проблема с производительностью).

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

Мне показалось это странным и я начал изучать код и искать различия. А потом в какой-то момент я решился на святотатство. Взял и написал свою реализацию оригинальной функции Kotlin. И оказалось, что моя функция работает быстрее.

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

Имеет ли смысл “обычному разработчику” ковыряться в функциях языка и как найти на это время?

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

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

Но уже начиная с уровня мидла нужно стараться лезть под капот. Анализируя код фреймворков, ты многому учишься. Ты учишься правильному подходу к проектированию. Ты узнаешь много нового, того, о чем тебе не расскажут ролики на YouTube.

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

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

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

JetBrains приняли твои предложения по изменениям — как это формально происходило?

Здесь все достаточно просто. У JetBrains есть открытый youtrack и кто угодно может зайти туда и создать свою issue.

Сначала это казалось мне каким то священнодействием. Как это, создать issue на доработку Kotlin?? Это же могут делать только небожители). Но нет, на самом деле любой может сделать это.

Что меня поразило, так это уровень разработчиков JetBrains. Разработчик, назначенный на issue, сходу понял суть проблемы, хотя некоторые оптимизации уходят глубоко в byte-code и нюансы его генерации для Kotlin.

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

Kotlin меняется, в том числе и с твоей помощью, каким ты видишь его будущее?

Здесь я могу немного пофантазировать и помечтать. Kotlin очень классный, гибкий и удобный язык. И мне кажется он вполне может отобрать часть рынка Enterprise у Java и C#. По сути, он уже это делает, и я знаю уже довольно много проектов, где Kotlin используется на бэкенде.

Думаю что KMM это движение в очень правильном направлении. Миру не хватает какого то одного удобного языка, который бы работал на всех платформах. Не только iOS и Android, а еще и на десктопах, в Web и желательно на встроенных устройствах.

И я думаю что Kotlin это очень удачный кандидат на эту роль. Я очень надеюсь, что Kotlin удастся занять эту нишу и стать таким языком.