Интервью с head of mobile Яндекс.Транспорта

На мероприятии от подкаста Подлодка познакомился с Женей Кателла. Узнал, что он не только ведёт подкаст и работает в Яндексе, но ещё добрый открытый парень, который работал раньше джавистом на бэке. Тут я понял, что о переходе из бэка в мобилки стоит расспросить поподробнее.

И благодаря Жениной открытости получилось объёмное интервью. Он рассказал, чем мобилки круче бека, как развиваться разработчику, как устроен процесс разработки в Яндексе и многое другое. Я разделил интервью на части и самый сок выложу сюда, в канал. Полную версию отредактирую и залью позже на Хабр или VC.

Читайте, наслаждайтесь, ставьте классы.

#интервью #Яндекс #mobile

— как ты попал в айти?
Тут история в трех актах. Хотелось бы рассказать вдохновляющую историю о том, как я что-то сложное запрограммировал в 10 лет, но нет. Началось все, когда мне было лет 6 – с компьютерных игр. Позднее иногда баловался с MS Paint, Powerpoint (почему-то мне это казалось интересным), Corel Draw. Но это случалось редко и бессистемно. Большую часть времени я играл. И все это время в голове сидело чувство, что это все, конечно, хорошо, но было бы круто научиться делать с помощью компьютера что-то полезное и «серьезное».

В 9 классе я увидел у старшего брата книгу по Turbo Pascal для студентов-первокурсников и неожиданно заинтересовался программированием. Я перешел из своей школы в лицей информационных технологий, а оттуда осознанно поступил в универ на специальность «Информационные системы и технологии». Я не до конца понимал, чем хочу заниматься, т.к. я очень плохо представлял продакшен-разработку. Но знал, что хочется работать в сфере, связанной с компьютерами.

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

К моменту выпуска из универа у меня был какой-то админский опыт с сетями и серверами, базовые знания программирования, но я не понимал до конца, чем хочу заниматься и не знал, как устроена разработка в «реальном» мире. Потом случайно узнал, что есть вакансия инженера-программиста в отделении РАН. Так я попал одновременно и в науку, и в какое-никакое программирование. Я писал на C# софтину для операторов крупного предприятия. Никакого rocket-science, но было интересно, хотя сейчас я понимаю, что наши поделки недалеко ушли от уровня универских лабораторных. К сожалению, не было рядом скиллового программиста, у которого можно было бы поучиться. Параллельно с основной работой я влез во фриланс-проект на PHP, где первый раз самостоятельно взаимодействовал с заказчиком.

— как получилось, что ты работал в Хабаровске бэкендером, а теперь хэд мобильной разработки в Яндексе?
Череда случайностей 🙂 Я работал java-бэкендером в Хабаровской компании, а в свободное время делал парочку фриланс-проектов под Android. Было интересно изучать что-то новое и обкатывать привычные подходы из бэкенда на андроиде. Потом в компании произошел ряд изменений, большинство стоящих сотрудников уволились. Я не стал исключением и начал собеседоваться везде, где только можно. В Хабаровске идти было некуда, поэтому я рассматривал релокацию в Москву или Питер. Изначально целился на бэкенд, но было интересно попробовать себя и в «серьезной» мобильной разработке. В итоге у меня было два оффера в Москву. Один на бэкенд в неизвестную мне на тот момент компанию, второй – на мобилку в Rambler. Рамблер был больше на слуху и условия предложили получше. Так я стал мобильным разработчиком. Ну а дальше типичная карьерная история: сначала был миддл, потом стал ведущим разработчиком на проекте, затем возглавил Android-отдел в Рамблере. Ну и наконец, перешел в Яндекс на позицию руководителя мобилки на проекте.

— как ты изучал андроид?
Когда я начал заниматься андроидом, у меня уже была база для понимания, что есть хороший код и хорошая архитектура, что – не очень. Помогли книги «Совершенный код» Макконелла и «Архитектура корпоративных программных приложений» Фаулера. А дальше – документация на developer.android.com как основной источник истины, статейки в интернете про отдельные тонкости и нюансы. Некоторые вещи было проще и интереснее изучать, глядя прямо в исходники.

И самое главное – практика. Например, узнав, что в андроиде образца 2015-2016 года для DI принято использовать Dagger, а в качестве архитектурного паттерна presentation layer’а – MVP, я сделал пару тестовых приложений, чтобы лучше разобраться, как правильно все это вместе готовить.

— с какими трудностями столкнулся, когда переходил на мобилку?
Хороший вопрос. Наверное, главная трудность – это Android SDK и его документация. В нем много нюансов (читай – «костылей»), которые постигаются только опытным путем. Первое время часто было так, что я делаю что-то по документации, а оно или совсем не работает, или работает не так. Потому что документация была печальная и на полноту претендовать не могла. Сейчас стало получше, но не идеально.

Ну и от фрагментации платформы никуда не денешься. Ужасно бесило тратить по 4-5 часов на баги, которые происходили только на конкретной модели телефона. Помню баг, что на одном самсунге цифра "7" отрисовывалась с противоестественным смещением по вертикали. В порядке бреда поменял файл шрифтов c otf на ttf. Всё починилось. Что? Как? Почему именно на этом телефоне? Ответа у меня до сих пор нет. Было трудно смириться с тем, что для Android это нормально 🙂

— это смешно. чем же мобайл круче бэка?
Несколькими аспектами.
Во-первых, результат труда среднестатистического мобильщика намного ближе к пользователю. Это та самая пресловутая история о том, что можно показать своей маме, что именно ты сделал в продукте. Несравнимо сложнее объяснить, что я написал сервисы бизнес-логики, а над ними сделал фасад, который вывел на контроллер API, откуда я отдаю клиентам json’ы.

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

В-третьих, мобилка сильно больше позволяет экспериментировать. Размер кодовой базы среднестатистического мобильного приложения не настолько огромен, чтобы не иметь возможности что-то радикально менять. Для многих приложений это нормальная часть жизненного цикла – раз в 2-3 года что-то кардинально переписывать или делать редизайн. Кто-то может себе позволить всё переписать с нуля, когда стало совсем сложно. Субъективно кажется, что в мобилках такое случается несколько чаще, чем в бэкенде.

Ну и наконец, и это сейчас 100% субъективный момент, мобильные коммьюнити в России сейчас одни из самых дружных и сплоченных.

— а какие минусы у мобилки? или чем бэк круче?
У меня есть один спорный аргумент – в бэкенде я чаще сталкивался с объективно сложными задачами. Под словом «объективно» я подразумеваю какие-то не вендор-специфичные ограничения, которые обязан обходить. Здесь нужно продумать, как хранить данные денормализованно, чтобы искались быстрее. Сделать механизм транзакций, чтобы все не лочилось намертво. Решая такие задачи, ты понимаешь, откуда берутся ограничения, и они не вызывают у тебя баттхерта. В свою очередь в Android я слишком часто сталкивался с проблемами, которые вызваны только тем, что Android SDK неудобный и ни разу не developer-friendly. Бесчисленное количество раз приходилось сидеть и ловить себя на мысли, что уже в сотый раз пишешь костыли, чтобы просто отрисовать на экране список элементов, и он мог нормально, плавно скроллиться. Это не очень мотивирует.

Если обобщить, то в большинстве случаев мобилка – это тонкий клиент. Т.е. она получает данные с сервера и показывает их в своем интерфейсе. Пользователь жмет кнопку – данные пересылаются на сервер, сервер присылает ответ, клиент перерисовывает интерфейс. Всё. А вся «реальная» работа выполняется на сервере. Точно знаю, что для кого-то этот тезис валидный ответ на вопрос, чем бэк круче мобилки. После перехода из бэка в Android я первое время тоже так считал. Сейчас изменил свое мнение, т.к. все-таки одно без другого смысла не имеет, и просто некорректно сравнивать важность абсолютно разных задач.

В конечном итоге, я теперь понимаю, что никто не круче 🙂 Это просто разные инженерные задачи)

Как развиваться разработчику

Изначально вопрос звучал «как развиваться мобильному разработчику?», но ответ Жени тянет на целую статью и будет полезен каждому деву.

Тут у меня ответ многоуровневый. Во-первых, нужна хорошая база. Сюда я отнесу того же Макконелла и Фаулера. Понимание принципов-аббревиатур (SOLID, KISS, DRY и прочее) тоже никогда никому не вредило.

Когда есть какая-то база, нужно прокапывать свою платформу в глубину. StackOverflow driven development никто не отменял, конечно, но с таким подходом глупо надеяться, что сможешь знать эффективные решения повседневных задач. Поэтому стоит изучать документацию, читать исходники, искать источники новых знаний и подходов. Экспериментировать, но без фанатизма.

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

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

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

Горизонтальный переход. Был Android – стал iOS. Был бэкендщик – перешел в мобилку. Ну и так далее. Тут мне особо нечего прокомментировать, кроме того, что нужно уметь самому себе ответить на вопрос «зачем». Если устал от Android, сил нет больше им заниматься и вообще перегорел – уйти в тот же бэкенд вполне хороший вариант. Просто перейти, потому что там трава зеленее – так себе вариант, т.к. придется много своих прикладных скиллов оставить позади.

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

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

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

1. Всегда стоит смотреть не только на свои задачи, но и за пределы. Тимлид должен быть драйвером изменений в команде. Если есть амбиции тимлида – нужно учиться подмечать проблемы и точки улучшений, чтобы превращать их в задачи для команды. Разработчик, который помимо своих задач часто приносит какие-то здоровые адекватные инициативы по улучшению качества кода, всегда будет особенно заметен на радаре своего руководителя.

2. Второй скилл очень связан с первым. Нужно учиться смотреть на любые задачи, технологии, рефакторинги и процессы с точки зрения их влияния на продукт в целом. Нужно всегда уметь ответить на вопрос «а зачем я это делаю»? Условно, вот хочу я затащить библиотеку для DI. Если я это делаю, потому что она сейчас в тренде и все авторитеты индустрии выступают на конференциях, рассказывая про нее – это плохой знак. Надо всегда уметь дать максимально внятно оценить соотношение того, сколько сил придется потратить на какое-то действие к тому, какое влияние оно окажет на проект.

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

4. Также, во многих компаниях и командах тимлид – это важный партнер менеджера, будь то продакт или проджект-менеджер. Поэтому всегда стоит быть в курсе того, как устроены процессы, и постоянно думать о том, что в них можно подтюнить. Это больше про проджектовую часть. Если говорить про продуктовую – надо учиться не стесняться задавать вопрос «а зачем мы это делаем». Не во всех командах есть здоровая культура общения продуктового менеджмента с разработкой, поэтому задачи могут прилетать от людей, которых видишь только раз в год на корпоративе. С этим надо бороться. Если продакт и тимлид регулярно общаются – это помогает обоим принимать более качественные решения.

Планы на 2020 год

Самое время, чтобы придумать, чем заняться в новом году. Что нельзя пропустить в 2020м? Какие курсы стоит изучить? Что почитать? Какие фильмы посмотреть? Какие приложения скачать? Куда записаться? На какие мероприятия сходить?

Итоги 2019

В 2019 году было очень много технологических новостей. Вспомним быстро, бегущей строкой.

Первая фотография чёрной дыры, первая летающая платформа, первый складной смартфон, первые спутники Starlink и первый твит через них же. Microsoft купил GitHub, Kotlin стал основным языком для разработки под Android, все мы глубже погрузились в DevOps, выросла популярность Go. ИИ стал умнее, а киберпанк всё ближе: расплодились нейросети, дипфейки, боты.

Это в мире. В России же всё веселее: Яндекс создаёт, Сбербанк покупает, а Рамблер отжимает.

Друзья, всех поздравляю с Новым 2020 годом! 🎄🎉✊😎

Желаю писать больше кода

Быть топовыми software инженерами

Крутых идей

Никогда не сдаваться и идти к своей цели!

Наткнулся на итоги года и десятилетия от The Bell Tech

🥂 Друзья, мы поздравляем вас с наступающими праздниками и желаем хорошо отдохнуть! А мы уходим на каникулы до 9 января. Пока нас нет, почитайте итоги года и даже десятилетия для российского интернета:

🔺2019-й во многих отношениях стал кризисным годом: закон о суверенном рунете, кибервойна США и Китая, разочарование инвесторов и невзлетевшие идеи, обещавшие технологические революции. Обо всем этом и о том, что ждет за поворотом — тут.

🔻Рунет за десять лет изменился до неузнаваемости: в 2009 интернетом пользовался 31% россиян, сейчас — почти 80%. Из маргинального пиратского царства российский интернет превратился в место, где можно подать документы на загранпаспорт, а за контент почти привыкли платить. И, конечно, рунетом заинтересовалось государство. Итоги десятилетия — тут.

Java Марафон 2

Новому джава марафону быть. Про предыдущий можно прочитать здесь — https://yangx.top/java_developer/424. Новогодние праздники выдались продуктивными, и я почти дописал программу марафона. Подробности будут через неделю, когда все начнут выходить из спячки. Кодовое название марафона Java Core Challenge