Денис Неклюдов интересен Android-разработчикам по целому ряду причин. Он занимается «Android Dev Подкастом», выступает на конференциях, посещает саммиты GDE — в общем, вовлечён в жизнь сообщества самыми разными способами. А поскольку сейчас живёт в США и работает в Lyft, может сравнить западную ситуацию с российской.
И в преддверии Mobius 2019 Piter, где он расскажет об «архитектуре с прицелом на масштабирование», мы расспросили его обо всём этом понемногу. Чем российский подкаст может быть интересен западным слушателям? Каково работать там, где счёт мобильных разработчиков идёт на сотни? Что не так с решениями от Google для Android-разработчиков? А что не так с использованием смартфонов в целом?
Подкасты
— Ты участвуешь в Android Dev Podcast, а недавно возник ещё и Flutter Dev Podcast — как произошло это «почкование»?
— Изначально я был самым главным троллем Flutter. Не дадут соврать те, кто был на саммите GDE. Я прямо главным менеджерам Google говорил: что это за поделка такая, как вы можете его ставить рядом с нашим серьёзным взрослым Android?
Но через пару месяцев после того, как я это всё сказал, они вышли в релиз, я сам попробовал всё своими руками, посмотрел, что можно с этим делать, и понял, что это вовсе не игрушка.
Сначала-то мы воспринимали, что там какая-то виртуальная машина, JavaScript. А потом оказалось, что всё компилируется в нативный код, и действительно работает быстро на обеих платформах. При этом тулинг достаточно взрослый для такой экспериментальной, казалось бы, платформы. И оказалось, что язык Dart не так уж плох. Да, это не привычный нам Kotlin, но очень даже взрослый и хороший язык со всеми прелестями современных языков программирования.
Я изменил своё мнение, и стало ясно, что у Flutter есть перспективы. Даже React Native, Xamarin и другие фреймворки от сторонних разработчиков получили распространение, а тут поддержка Google, да ещё и слухи о новой операционной системе Fuchsia, где Dart и Flutter будут использоваться в первую очередь.
Но не будем же мы в Android Dev Podcast освещать все новости Flutter. И тогда у меня возникла идея, что неплохо было бы сделать отдельный подкаст. Я обратился к своему старому товарищу еще с университетских лет, Жене Сатурову, говорю: «Не хочешь ли ты выступить с инициативой? Я второй подкаст не потяну, а ты кровь помоложе, может быть, ты возьмешь». И так родился Flutter Dev Podcast.
— Когда одна и та же компания Google развивает и нативную Android-разработку, и Flutter, начинающим разработчикам может быть непонятно «ну и куда мне идти». Кажется ли тебе это проблемой?
— Если новички не могут определиться, пусть сразу идут в разработку игр на Unity! А если серьёзно, то описанный эффект есть, но Google и так давно сидит на двух стульях: web и native. Есть вещи вроде Progressive Web Apps, которые тоже в Google разрабатываются. Вроде же есть нативные платформы, зачем вы свои PWA суёте? А ещё есть инициативы вроде WebAssembly, связанные с исполнением всего, что только можно, в браузере (Google изначально всё-таки из мира веба).
Поэтому Google не впервой создавать разные рабочие места для разных категорий решения одной и той же задачи. Это такая огромная махина, где внутри есть разные борющиеся друг с другом маленькие компании. Поэтому ничего удивительно, что существует конкуренция внутри одной корпорации.
— Продолжая тему подкастов: у компании Lyft, где ты работаешь, в этом году появился свой подкаст о мобильной разработке. Ты имеешь к этому какое-либо отношение?
— Они начали его до того, как я пришёл: когда делать подкаст собирается компания, это не «за неделю записали-выложили», а долгий процесс согласования того, о чём можно говорить, о чём нельзя. Но меня обещали пригласить туда на одну из тем (ведущим не звали).
Подкастов о мобильной разработке много — недавно появился ещё один русскоязычный. Думаю, что чем их больше, тем лучше: выше качество тех, кто хочет быть на вершине. Но понятно дело, что слушателям приходится потреблять все больше и больше материалов. Так же и с митапами, конференциями, площадками для докладов.
— Ещё есть подкаст The Context с Артёмом Зиннатуллиным, и раз вы с ним теперь работаете в одной компании, напрашивается вопрос, не хотите ли вы как-то объединить усилия.
— Насколько я знаю, Артём уже пропускал некоторые выпуски The Context ввиду большой занятости на работе. Но к нам в Android Dev Podcast он приходит тоже с радостью, всё зависит от тем. Артём не занимается редактурой выпусков, а приходит с экспертным мнением. А мне часто нравится заниматься редактурой, и тут мы занимаемся абсолютно разными вещами.
— Когда занимаешься русскоязычными подкастами, живя за рубежом, ощущается ли это как две параллельных жизни, где на работе не слушают твой подкаст, а в подкасте только с твоих слов знают что-то твоей работе?
— В Сингапуре так не ощущалось, а в США действительно ощущается, что это два разных мира. В России меня знают, моё имя уже имеет какой-то вес. В США никто меня не знает, и в ответ на слова «У меня есть подкаст» спрашивают, почему его не слышали. Потому что он на русском. Тут я, конечно, теряю.
Поэтому моя личная инициатива — делать англоязычные выпуски подкаста, больше выступать на английском языке, чтобы расширить аудиторию. То, что мы обсуждаем в России, точно так же актуально и на Западе, много незаполненных ниш. Мне кажется, темы, которые мы поднимаем в подкасте, было бы неплохо почаще освещать здесь.
— У англоговорящих слушателей уже есть подкасты вроде Fragmented — что, по-твоему, может дать Android Dev Podcast, чего нет у них?
— Мне всегда хотелось верить, что мы ближе к слушателю. Мы не стараемся быть объективными, и часто у нас личное мнение остаётся личным мнением, высказанным публично. Но при этом это мнение имеет какой-то большой опыт за своими плечами, и мы не стесняемся в своих высказываниях.
Возможно, на Западе это как раз и не зайдёт, поэтому Fragmented — более рафинированный подкаст, где мало какой-то подноготной, деталей и сложностей (которые многие просто не поймут). В погоне за высоким числом прослушиваний для широкой аудитории некоторые подкасты убирают сложные темы для обсуждения.
— Если говорить не о подкастах, а об Android-разработке, ощущаешь ли в ней заметную разницу между США и Россией?
— Мне кажется, да. Я ещё не готов судить строго, но первичное ощущение (не такое жёсткое, как в Сингапуре), что все совсем слабо интересуются своей профессией и своими навыками. Здесь, когда в компании работает множество разработчиков на одной платформе, люди просто сидят, занимаются своим задачами, для них Android — это не их жизнь, не их страсть, не их увлечение, а просто список задач, которые они должны реализовать.
Большие масштабы в мобильной разработке
— Ты работаешь в компании, где мобильных разработчиков больше сотни. Задают ли постоянно вопрос «У вас же приложение из примерно одного экрана, что там такой толпой делать»?
— Я и сам изначально об этом спрашивал. Ответ приходит, когда ты попадаешь внутрь всего этого.
Во-первых, нельзя сказать, что у нас приложение из одного экрана. Начнём с того, что приложения два (водительское и пассажирское), а дальше, если говорить о пассажирском опыте, то у нас приложение с автомобилями, самокатами, велосипедами, автономными машинами и с разными фишками для разных регионов (как платёжными, так и пользовательскими).
А во-вторых, очень много сложностей приходит с масштабом. Возникает много работы, связанной с продумыванием метрик, с формированием экспериментов, отслеживанием того, как идут твои предыдущие работы. Масштаб в виде миллионов пользователей сказывается на времени разработки, теперь я это лучше понимаю.
Мы разделены на маленькие кросс-функциональные субкоманды, где каждый отвечает за какой-то раздел. Кто-то отвечает за поездку, кто-то за велосипеды и самокаты, и так формируется два десятка разных команд, в которых по два-три разработчика. Я отвечаю за часть, связанную с идентификацией пользователя. И я хотел бы, чтобы для этой части появился ещё коллега, увеличив наш общий счётчик.
Если говорить о разработчиках маленьких приложений, которых полно среди наших читателей, то как раз получается, что мы просто состоим из десятка маленьких приложений внутри одного большого.
Примерно так же ситуация выглядит в очень многих крупных приложениях. И разделение на feature-команды, и metric driven development, где метрики движут всем, и стартап-подход, когда сначала сделаем MVP, а потом уже доведём до хорошего состояния: у кого-то это в виде всего продукта, а у кого-то в виде внутренней фичи. Даже Google свои маленькие команды ставит так, что они словно стартап, и старается минимизировать бюрократию и долгие циклы разработки.
— А как выглядит работа конкретного сотрудника в такой ситуации? Можешь рассказать о какой-нибудь своей объёмной задаче?
— На создание профиля пользователя у меня ушло два месяца, хотя само по себе оно не сложное. Сам экран новый, ранее у пользователя не было профиля, были только настройки. Помимо того, что нужно было сверстать готовое, выяснилось, что с архитектурной точки зрения некоторых компонентов не хватает, понадобилось пойти поконтрибьютить в архитектуру, помочь ребятам.
Ещё я решил поэкспериментировать с Dagger, это тоже заняло время. Также нужно было продумать метрики, построить дашборд, собирающий аналитику успешности эксперимента, на это ушло время. Потом я начал добавлять во внутренние экраны профиля существующие экраны из настроек и обновлять.
Обновление по «правилу скаута» потребовало отрефакторить то, что тронул. Рефакторинг на последнюю архитектуру занял тоже какое-то время. Плюс у нас есть дизайн-система, и некоторые компоненты не реализованы из последних утвержденных элементов. Чем дожидаться команды, которая пишет эти элементы, я взял и помог им законтрибьютить к ним свою работу, чтобы не быть заблокированным.
Вот из всего этого сложились два месяца работы, которая на первый взгляд казалась на пару-тройку недель.
— Когда хочется во время выполнения задачи «поэкспериментировать с Dagger», поощряются ли такие эксперименты?
— Зависит от уровня инженера. Я думаю, если инженер начального уровня, то у него с менеджером чёткое понимание, что он не отвлекается на какие-то архитектурные эксперименты, потому что он сам ещё зеленоват для этого.
А от опытных инженеров прямо в обязанностях требуется приносить вклад во что-то широкое: «organization-wide» или, как минимум, «application-wide». Поэтому деваться некуда: даже если не очень интересно заниматься архитектурой, но хочется развиваться, придётся связывать свою жизнь с чем-то большим, чем просто фичи.
— А если поэкспериментировал, и результат оказался удачным, дальше это становится общей политикой, или может оставаться в пределах команды?
— Очень редко остаётся внутри одной команды. Обычно, если кто-то начинает эксперимент, это сразу согласуется с core architecture-командой и в последующем рассматривается как общая хорошая практика. Например, сейчас две команды параллельно экспериментируют с Redux, чтобы понять, кто из нас победит, чьё решение будет более универсальным, и мы начнём его использовать во всей компании.
— Рост числа людей в команде — это ещё и рост «бумажной работы», когда не кодишь, а делаешь что-то сопутствующее. Понятно, что это необходимо, но насколько это тормозит разработчика по сравнению с тем, как в маленьком проекте он бы «просто фигачил фичи»?
— Снова зависит от уровня инженера. Если инженер — middle или начинающий senior, то к нему нет требования писать много документов, он сидит и фигачит фичи под надзором своего старшего инженера. А вот старший инженер уже обрастает менеджерскими обязанностями, как и в любой другой компании. Ему от общения с начальником, если это стартап, или написанием документов для своего менеджера, если это крупная компания, никуда не деться.
— Когда делаешь Android-приложение для такси, проблемы и актуальные вопросы примерно те же, что у других крупных приложений, или есть своя специфика?
— Проблемы, с которыми мы сталкиваемся, очень похожи. К примеру, проблема многомодульной сборки добавляет инфраструктурным инженерам забот на каждый день одинаково, поэтому не удивительно, что Uber, Facebook, Airbnb и Lyft используют одну и ту же систему сборки Buck.
Другие тоже к ней присматриваются, достигая наших масштабов, и это подтверждает, что проблемы те же. Параллельно происходят одинаковые процессы — например, все потихоньку становятся реактивными. Ну, кто-то более консервативен, у кого-то всё ещё на коллбэках, никакой реактивщины и даже никакого Kotlin, потому что масштаб и квалификация разработчиков не позволяют это сделать.
Отличие от ситуации в СНГ здесь в том, что мы часто ходим друг к другу и говорим: «Ребята из Gradle, подсобите с тем-то». То есть, пока в СНГ пользуются инструментами, написанными в Долине, тут мы ещё и друг с другом постоянно общаемся.
Прав ли Google
— Недавно у Джейка Уортона был ряд критических высказываний в адрес гугловых решений для Android-разработки, и ты с чем-то из этого соглашался. Что именно, по-твоему, Google делает не так?
— Там было обсуждение, что не нужно было называть ViewModel и засовывать в неё контекст. С этим, я думаю, тоже многие согласятся. Меня очень расстраивает, что многие воспринимают библиотеки от Google как источник неоспоримый и самый правильный.
К нам на интервью приходят кандидаты, и 9 из 10 используют Android Architecture Components для решения задач, которые мы им ставим для описания дизайна приложения, которое они писали бы. Тут я не могу не согласиться с Джейком, что ViewModel имеет спорные моменты, хотя lifecycle при этом всем очень нравится.
Что касается библиотеки Data Binding, показательным был Android Summit этой осенью, где на fireside-чате пять из десяти вопросов было о том, что что-то не работает в Data Binding. Инструмент был слишком мощный, и по моему личному мнению, так и не доведённый до ума для многомодульности и быстрой сборки. Но при этом все его восприняли как истину.
На самом деле он достаточно удобный, но Google, по моему мнению, не выделил достаточно ресурсов, чтобы продолжить его поддерживать. И тут комьюнити отхватило: доверились Google, а поддержки достаточной и не получаем.
— Часть людей недовольна тем, что многие решения от Google появились только в последние годы: «Хороша ложка к обеду, вы годами слоупочили и сообщество само разобралось, а теперь проснулись». Что ты по этому поводу думаешь? Почему компания так себя ведёт, и плохо ли это?
— Я это всё вижу с точки зрения выделения бюджетов и с точки зрения стратегии каких-то отдельных вышестоящих менеджеров, которые раньше имели одну точку зрения или были другие просто люди, а теперь изменились, с другим подходом.
То есть это не Google, а просто пара-тройка людей, которые принимают решения в Android-команде распределения ресурсов. Вот появились у них ресурсы, devrel-ы, и разработчики библиотек, которые захотели заниматься именно этим — появились решения от Google. И однозначно хорошо, что они появились! Я больше расстраиваюсь за сообщество, которое безоговорочно верит тому, что им сказали, и не даёт какую-то критическую оценку.
— Google в недавнем видеокурсе по Android-разработке на Udacity даёт вперемешку и базовые вещи, необходимые всем, и свои решения вроде Data Binding. Видишь ли ты проблему в том, что незнакомые с контекстом начинающие разработчики воспримут их как непреложную истину, а не как опциональный вариант?
— Видеокурсы на Udacity — это отдельная история. Я знаком с Android-курсами там ещё с 2016 года, когда мы делали по ним первый курс Study Jam. Там в целом всё шло отлично, базовые вещи были отлично объяснены. Но из восьми уроков курса два урока посередине — неперевариваемые, непроходимые, очень сложные темы ContentProvider. Зачем новичку знать, как устроен ContentProvider, уже в 2016 году было непонятно.
У меня ещё тогда возникли вопросы по поводу того, как они составляют темы и расставляют акценты. Поэтому слова, что сейчас там всё вперемешку, меня уже ничем не удивляют. Но видеокурсы, стоит отдать должное, вообще всегда сложная тема. Они устаревают, как только ты их выложил.
Очень сложно в подготовке хорошего качественного материала. Много где в комьюнити можно получать свежие источники обновления и понимание того, что и как происходит. Но если нас читают новички — идите работать в любую компанию, которая занимается мобильной разработкой, там вас сразу научат всё делать правильно. Что-нибудь более-менее актуальное, да узнаете, из уст в уста.
— Тут у новичков возникнет вопрос «как попасть туда без опыта, если ещё и не просидел год над курсами».
— Это очень хороший вопрос. Я считаю, что во многие адекватные компании возьмут за базовые знания computer science и без знания какого-то фреймворка. Потому что узнать фреймворк можно всегда, а получить базовые знания по решению алгоритмов, знания объектно-ориентированного программирования и просто адекватного суждения сложно получить где-то. Это основа. С основой вас возьмут. А если у вас есть ещё и английский язык, то перед вами вообще двери открыты.
— Ранее тебя интересовала платформа Android Things, а недавно для неё всё стало довольно печально. Какой вывод нам стоит извлечь из истории? Что никогда нельзя полностью доверять крупным компаниям и нужно пользоваться любой платформой с расчётом на то, что завтра её может не стать?
— Вывод — что надо следить за трендами. Уже не первый год есть тренд на то, что любое электронное устройство, будь то пылесос или микроволновка, начинает управляться из облака, как бы нам, параноикам, грустно от этого не было.
Android Things как платформа слишком перегружена для простых задач Android, при этом не сильно помогает с точки зрения облака или какого-нибудь machine learning (из-за, опять же, performance-проблем). Это наводит на мысль, что Android Things не такая уж и классная. Но я сам был тем, кто до последнего верил, что эта платформа — хоть какое-то решение проблем того, что железяки с Kickstarter перестают обновляться. Что Google будет хотя бы обновлять операционную систему и выпускать security-патчи.
Поэтому я тоже немножко расстроен, но следите за трендами: скажем, из расписания недавнего Google Cloud Next хорошо видно, что IoT в Google по-прежнему очень сильно в фаворе, и есть большой акцент на размещении вычислений на двух сторонах — на облаке и на маленьких устройствах.
Вред и польза приложений и соцсетей
— Ты писал, что человечеству нужно меньше пользоваться смартфонами, а от мобильного разработчика такое услышишь нечасто. Можешь рассказать подробнее свою позицию?
— Недавно читал пост в Telegram-канале одного русскоговорящего жителя Китая о том, как он расстроен молодёжью, которая всю дорогу в метро смотрит ролики в TikTok — в отличие от его родных петербуржцев с книжками
Но главная проблема в том, что когда мы храним какую-то информацию в нашем теле — только мы владеем этой информацией. Когда мы храним в нашем блокноте — только мы владеем информацией. А когда мы храним информацию в нашем смартфоне — не только мы владеем этой информацией, что меня очень печалит.
Вроде бы смартфон — продолжение нашей ладони и дополнение наших глаз и , но мы им на сто процентов не владеем. Факт того, что человек начинает слишком сильно доверять дополнительному устройству, не может не заставлять задуматься.
— А для тебя самого важно, работаешь ты над условным TikTok или над близким тебе лично приложением?
— Жизнь в Сан-Франциско не мёд, и нужно иметь какое-то оправдание, чтобы находиться с семьей здесь. Как раз моя работа и сфера, в которой я работаю, — один из таких пунктов. Не просто ради зарплаты или реализации себя как разработчика, но и с точки зрения совпадения моих ценностей с ценностями бизнеса.
— Раньше ты работал в стартапе 90 Seconds, который занимается видео — это тоже совпадало? Человечество сейчас не слишком много видео снимает?
— Хороший вопрос. Это профессиональный инструмент, это не было развлечением. Просто вместо того, чтобы люди при работе над видео использовали в переписке Telegram, WhatsApp или Google Docs, мы делали для них платформу. Это B2B-платформа, где малый бизнес соединяется с большими заказчиками, поэтому это другая история. Но мне было бы грустно, наверное, работать над приложением, монетизация которого — отъём денег у школьников.
— Ты человек, который вовлечён в жизнь сообщества, но при этом не пользуется соцсетями. Многое происходит в Twitter, тот же Джейк Уортон активно твитит — не оказываешься ли оторван от половины жизни сообщества, которая тебя так интересует?
— Как мне кажется, в русскоговорящим сегменте без соцсетей отлично получилось благодаря подкасту, конференциям и большим чатам в Telegram. В западном мире тоже есть закрытые чаты топовых разработчиков, тоже есть конференции и есть подкасты. Я думаю, что и здесь у меня получится обойтись без Twitter.
— Вопрос напоследок: чего нам ждать от твоего доклада на Mobius?
— В докладе я постараюсь отразить то, о чём разработчики на старте приложения не задумываются. Показать им, как они должны заложиться на масштаб без over engineering, и помимо этого отразить, как этот масштаб скажется на их жизни с точки зрения архитектуры мобильного приложения.
Мы будем говорить о многих вещах в разработки приложения, которые мы выучили, дойдя до масштаба сотен экранов, нескольких десятков параллельно разрабатываемых фич 60 разработчиками (и это только на Android). Цель моего выступления — поделиться большинством практик хорошего проектирования приложения и рассказать об ошибках, на которых мы учились и росли. Я хочу сохранить слушателям их красивые лобики от граблей, бьющих при выходе приложения из стадии «2-5 разработчиков и релиз раз в 2 месяца» в мир большого масштаба с кучей вытекающих из этого новых задач и инженерных вызовов.
Автор: phillennium
