«Приключение на 20 минут: взял и поменял язык». Личный опыт перехода на Kotlin
О себе
Это небольшое представление будет важно для дальнейшего обоснования своей позиции. Зовут меня Артемий, разработчик в компании i-Digital, еще в начале своего карьерного пути выбрал для себя основным языком Python и развивался по большей части в нем. В какой-то момент начал преподавать его молодому поколению разработчиков в частных студиях, а заодно брать студентов на личное обучение.
Я пришел в коммерческую разработку на определенный проект, который был реализован на Python, но основным стеком для компании являлся Kotlin. Несмотря на переход в разработку, я продолжен преподавать и занимаюсь этим до сих пор. Вот из такой стартовой позиции начнем наше повествование.
Что привело к смене языка программирования
Проект, на который меня взяли, подошел к своему логическому завершению. Какие-то задачки на Python еще оставались, и в теории я мог продолжать их копать. Но то был легаси код, оставленный древними сверхлюдьми без какой-либо документации, да и хотелось бы разбавлять рутину созданием новых и актуальных проектов. Вот тут у меня и появилась возможность перейти на Kotlin.
Опыта с этим языком у меня не было совсем, и вот я уже открываю свой первый проект, где нужно было просто поправить логи. В этот момент приходит осознание, что мне придется вновь освоить объемный пласт информации. Все крайне непривычное, а потому весьма интересное.
Таким образом я оказался в ситуации, где пришлось учить не кого-то, а себя любимого. А, как мы знаем, договориться с самим собой что-то не делать невероятно просто. Ну вот не любит наш мозг напрягаться и все тут.
Страшно, но надо
С чего начинать?
В начале обучения я обычно стараюсь найти какого-то ментора — человека, который уже давно занимается этим делом и готов передавать свой опыт. Я нахожу эту стратегию выигрышной. В этот раз с этим было легко, профессионалов вокруг меня много, так как весь коллектив разработки работал с этим языком, а значит всегда можно не просто проконсультироваться, так еще и найти несколько точек зрения на одну и ту же проблему. Но что делать с самостоятельным обучением, ведь постоянно выдергивать коллег, чтобы они тебе объясняли азы нельзя, бизнес не оценит.
Ну что ж, добро пожаловать в интернет, будем добывать информацию из него. Все же при переходе на новый язык не все приходится изучать с нуля. С нами остаются фундаментальные знания, понимание алгоритмов и структур данных, принципы хорошего кода по типу DRY, KISS, SOLID… И самое главное — умение искать информацию, формулировать вопросы и читать документацию.
И вот тут хочется остановиться и поговорить подробнее. Каждый из нас по-разному воспринимает информацию: кто-то лучше усваивает на слух, а кто-то лучше усваивает через текст. Стоит самостоятельно определить, какой формат вам больше подходит. Я бы рекомендовал использовать их все, но каким же образом?
Отвечая на вышепоставленный вопрос, я бы хотел апеллировать к своей практике.
Если у ученика возникают проблемы с усвоением материала, я предлагаю ему немного подготовиться и попытаться объяснить его мне так, будто учитель здесь он. Это похоже на широко известный метод Rubber duck debugging (метод уточки), который изначально предназначен для решения трудной проблемы путем делегирования ее мысленному помощнику — резиновому утенку.
При изучении нового материала легко столкнуться со сложной темой, которую не удается сходу полностью понять и запомнить. Попытавшись объяснить это своей уточке, мы задействуем и зрение, и слух, а также перерабатываем текст в речь, что позволяет нагрузить мозг со всевозможных сторон. Это может показаться медленным, ведь «про себя» мы зачастую читаем быстрее, но лучше потратить это время сейчас и понять материал до конца, чем возвращаться и перечитывать его по несколько раз.
У меня и правда есть уточки на рабочем месте, хотя для этого способа достаточно просто иметь хорошее воображение.
Так вот, открываем документацию и понеслась. Да-да, именно документацию, я, все же, говорю про изучение второго языка, когда уже есть опыт в коммерческой разработке, а значит, и привычка работать с технической литературой. Конечно, бывают крайне плохие примеры таковой, когда приходится искать информацию в других источниках, но в случае с Kotlin она весьма информативна.
Я бы не советовал штудировать ее от корки до корки, но познакомиться с basics и concepts на начальном этапе необходимо. Безусловно, прочитать ее целиком будет весьма полезно, но мы же хотим как можно быстрее переключиться на новый язык, а значит, нужно быстрее добраться до реальных задач.
Практика
Разобравшись с документацией, срочно идем закреплять пройденный материал. Практика решает — и точка. Можно сколько угодно читать чужой код, но если не написать ни одной осмысленной строчки САМОСТОЯТЕЛЬНО, то толку будет маловато.
Можно придумать какой-нибудь pet-проект, и это будет весьма хорошим решением, но лично я побежал на leet code, заодно повторяя там всякие структуры данных по типу двусвязных списков, бинарных деревьев и прочего. (Конечно, все мы идеально помним сложность каждой операции над базовыми структурами, и если разбудить нас посреди ночи, сможем реализовать их, даже не открывая глаза).
Это дало мне возможность познакомиться с базовым синтаксисом и привыкнуть к нему. После решения задачи я каждый раз просматривал решения других пользователей, чтобы увидеть более лаконичный подход.
Да, иногда там может попадаться весьма хитрый код, который даже на свежую голову не с первого прочтения будет понятен, но, раз уж решил учиться, то придется напрягаться. Безусловно, код должен быть простым и легко читаться, так как в коммерческой разработке ты не один и жалеть своих коллег тоже нужно, но такая насмотренность обязательно сыграет в плюс при решении сложных задач.
Если до этого момента все было просто и привычно, то дальше начинается самое интересное. Каждый язык в базовой комплектации без фреймворков мало где используется, и Kotlin не исключение. Так как вся разработка в компании, где я работаю, ведется с использованием Spring Framework, то выбор для меня был предопределен. Не буду лукавить, поджилки у Python программиста затряслись, всё до жути необычное. В этот момент пришлось столкнуться со всеми стадиями принятия, которые показали, что пути назад нет.
Изучая этот обширный фреймворк вдоль и поперек чисто по документации, можно потратить не один год жизни, а значит нужно пойти от задачи. Благо, мой руководитель предоставил мне такую возможность и выдал сервис, который необходимо было переписать. Тут я понял, насколько глубока кроличья нора.
Плюсы смены языка находясь в компании, где вся разработка на нем
Первое, и самое приятное, это — коллеги, готовые отвечать на твои вопросы, которых будет очень много. Тут главное не перегибать. Не стоит бежать к ним с любой проблемой и просить помощи, лучше все же постараться найти решение самостоятельно. Но и не стоит упираться рогом в нерешаемую задачу, так как бизнес тоже ждет. Короче, в этом вопросе важен баланс: уважайте коллег, но старайтесь не затягивать разработку.
Второе, это ваш корпоративный gitlab, где уже находится мудрость ни одного поколения программистов, так что не брезгуйте пользоваться ей. Когда вы в самом начале пути изучения новых языков программирования/фреймворков/технологий, вам нужна какая-то опора, вектор, от которого стоит отталкиваться, и gitlab подходит для этих целей превосходно. По нему вы сможете отследить принятые в компании стандарты по взаимодействию с Rabbit/Redis/БД, посмотреть предпочитаемые библиотеки, а значит, сможете сосредоточиться на них.
Третье, и самое важное — ревью вашего кода. Сложно недооценивать этот процесс, но находятся программисты, которые воспринимают замечания по ревью как личное оскорбление, это не есть хорошо. Конструктивная критика, вот что это такое. Вся команда заинтересована в том, чтобы вы написали хороший код, так как рано или поздно им придется с ним поработать, так что стоит прислушиваться и перенимать опыт. Если есть возможность, старайтесь отправлять свой код на ревью к разным разработчикам. Чем больше профессиональных мнений, тем ближе истина. Опять же, не боимся оспаривать решение ревью и стараемся не просто бездумно исправлять, а разбираться, почему тот или иной подход лучше для решения поставленной задачи.
Да, почти всегда есть возможность просто найти человека, который разбирается в технологии, задавать вопросы ему, договориться о ревью вашего проекта, а примеры кода смотреть в github. Однако, существует огромная разница в продуктивности между созвонами с одним единственным ментором и нахождением в постоянном информационном поле множества коллег.
Одна ошибка и ты ошибся
В какой-то момент, коварный баг в вашем коде все же сможет залететь в продакшн и тут ничего нельзя сделать. Статистическая вероятность этого события на горизонте вашей карьеры равна 100%, поэтому не замыкаемся на моменте и двигаемся дальше.
Вот тут ручки могут опускаться, ведь навязчивая мысль, что на своем первом ЯП ты бы такого не допустил, ведь уже знаешь намного больше нюансов его работы, будет тебя преследовать. Но не стоит относиться к таким ситуациям слишком серьезно. Конечно, я сейчас пытаюсь усидеть на двух стульях сразу, так как существует репутация и обязанности перед клиентами, а значит такого лучше не допускать, но нервы и самоедство точно не помогут. Все же это очередная точка роста тебя как специалиста, и классная история, которой можно поделиться с друзьями. Только не забываем выкатить фикс побыстрее.
А что там с мотивацией
В первую очередь, стоит ответить самому себе на главный вопрос:
А действительно ли мне это нужно?
Да, вот такой простой и банальный вопрос, но почему-то мы упускаем его из вида. Думаю, все знают ощущение, когда ты принимаешь решение, что будешь бегать каждое утро, откажешься от всех вредных привычек, начнешь правильно питаться, читать по книге в день и вообще станешь сверхчеловеком. И даже стараешься жить этой идеальной жизнью, но, когда заканчивается весь запал, остается только этот единственный вопрос. Так постарайтесь задать его сразу. И, только ответив на него, можно пытаться выстраивать план.
Опять же, вернемся к важности применения новых знаний на практике. Нам гораздо проще отслеживать свой прогресс по каким-то проектам, которые можно потрогать ручками, наш мозг так устроен, что ему бывает тяжело работать в одном направлении, не видя результат. А если есть проекты это — прямое доказательство, что наша работа не пропадает даром, а значит и поддерживать мотивацию проще.
Еще очень удобно использовать какой-нибудь игровой подход, когда вы сами себе придумываете правила, при решении задачи. К примеру, когда я изучал Python, я старался решить задачу с помощью одной строчки. А вот при решении на Kotlin, очень весело записывать через цепочку вызовов. И выглядит эстетично, и заставляет подумать.
Простенький пример решения задачки через цепочку вызовов. Задача с code wars.
import java.math.BigInteger
object SumFct {
fun perimeter(n: Int): BigInteger = generateSequence(
Pair(BigInteger.valueOf(1), BigInteger.valueOf(1))
) {
Pair(it.second, it.first.add(it.second))
}
.map { it.first }
.take(n + 1)
.fold(BigInteger.ZERO) { acc, value -> acc.add(value) }
.multiply(BigInteger.valueOf(4))
}Заключение
Я сам еще продолжаю изучать Kotlin и его фреймворки, столь объемные технологии невозможно познать за год, но этой статьей я хотел показать, что не стоит бояться и избегать смены ЯП, особенно если есть возможность сделать это, уже работая в компании. Весь ваш технический бэкграунд перейдет с вами, а уж научиться объяснять «тупой» железке какой алгоритм действий она должна выполнить, чтобы мы были довольны, не так уж и сложно. Все же команды новые, а смысл прежний. Страх перед неизведанным пройдет очень быстро, а знания и умения это новые возможности.
Ну и в завершении, я хотел бы сказать несколько слов. Вот эти слова: Олух! Пузырь! Остаток! Уловка! Все, всем спасибо!
