Какими будут мобильные технологии буквально завтра рассказывают руководители «Сбера», «Яндекса» и «Авито».
Подслушано на YaTalks 2021.
С чего начать путь в IT?
Условие. К вам за советом пришел человек, решивший обучаться мобильной разработке. До этого он был инструктором по горным лыжам и в IT не развивался. У него нет опыта, но есть свободный год на обучение. Как ему действовать?
На начальном этапе максимально важна практика. Читать книжки можно, но развитие будет медленным, не интерактивным.
Лучше выбрать курс на год (или два курса по полгода), и это будет самой сложной часть пути. Если есть деньги, стоит выбрать несколько курсов и посмотреть, где уроки сделаны наиболее понятно и качественно. Гарантия стажировки и дальнейшего трудоустройства – тоже важный момент в обучении.
После обучения самое сложное – адекватно оценить свою готовность к работе. Я помню, как боялся проходить первые собеседования, чувствуя себя дураком, и прокрастинировал. Было страшно. Важно, чтобы у вас была поддержка и помощь.
Я в «Сбере» сам провожу собеседования и строю воронку проверки технических знаний. К нам часто приходят люди на начальном этапе, и при отказе им нужно что-то порекомендовать. Вот мой совет.
Не нужно выбирать первую попавшуюся образовательную платформу. Разработка – очень доходная сфера, многие хотят быстро перепрофилироваться. И все же я не советую доверять курсам, которые гарантируют обучение за месяц / полгода / год / два года. За это время вы не успеете получить системные навыки, которые пригодятся в работе.
Я бы шел на курсы компаний, который трудоустраивают или берут к себе на стажировку. У «Сбера» есть такая школа мобильной разработки, после которой многие новички попадают на стажировку.
Еще одна важная тема, пока мало распространенная в России, – менторство. Его суть в том, что каждый может найти персонального наставника-эксперта. Он быстро натаскивает учащегося и дает рекомендацию, которую можно показывать при трудоустройстве. Найти работу после такого подхода намного легче.
Какой стек выбрать?
Условие. Вас наняли на должность СТО в стартапе. Все по классике: делаем убийцу «Инстаграма», социальную сеть с котиками, киллер-фича – короткие видео. Вам нужно выбрать технический стек для мобильных приложений. Выбранный стек нельзя будет изменить в течение пяти лет.
У меня бывали похожие ситуации, когда я залетал в маленькую команду, и нужно было сделать убийцу n-приложения.
Если пять лет нельзя ничего менять, мой выбор – нативный стек. Мы выбираем количество платформ, которые будем делать. Например, iOS и Android, ведь в мире мобилки вряд ли появится что-то более глобальное.
Берем по нативному девелоперу (по одному-двум на каждую платформу), одного бэкендера (по стеку: на iOS – это Swift, на Android – Cotlin).
SwiftUI в iOS – интересный вопрос. Да, если пять лет, то это нормальный срок, но зависит от даты первого релиза. Если начинать с последних версий iOS (14+), то SwiftUI – оправданный выбор. Будет проще найти разработчиков, ведь команда будет частично уходить. По стеку в плане фреймворков не брал бы ничего, что за 5 лет может умереть или развалиться.
Я за нативный подход, простые зависимости и скорость (без суперархитектур). Даже UNIT-тесты можно пропустить в первые полгода. Главное – чтобы запустилось, и люди скачивали.
Сперва я подумал про Flutter, но потом понял, что точно бы пошел в натив.
Бизнес-логику мы бы точно писали с Cotlin (на старте), ведь зачем писать два раза одно и то же. Я верю, что в ближайшие пять лет кроссплатформенный Cotlin станет совсем хорош.
SwiftUI – можно, но я бы подумал про кроссплатформенный compose. Он уже вышел в stable, и я верю, что с ним будет все хорошо. Я думаю, что будущее именно за декларативным UI. Сеть, если у нас Cotlin, будет Ktor. База – сложный вопрос. Сперва нужно собраться с командой и провести мозговой штурм.
Я за нативный стек, бизнес-логика – кроссплатформенный Cotlin, UI – нужно размышлять (возможно, compose).
Что изменили бы в своей карьере?
Условие. Расскажите, какие решения в своем карьерном пути вы считаете самыми удачными, а что поменяли бы, если бы была возможность?
Хорошее решение – переход из бэкенда в Android. Стандарты и общепринятые на бэкенде практики существуют давно, поэтому люди там проще относятся к работе: «Уже все написано, а я просто беру и делаю».
Мобилка развивается гораздо более динамично. Мы всегда «велосипедим». Для бизнеса это нехорошо, но для личности – очень полезно: ты постоянно развиваешься и пробуешь новое.
А изменил бы я свое взаимодействие с командой и свой подход к работе руководителем. Я пытался повысить себе зарплату, а мой руководитель говорил: «Тебе и так нормально, зачем тебе больше?» Я не понимал, как на это реагировать. Позже я узнал, как вести беседу, выходить на диалог. Мне это очень помогло, и больше тема не поднималась.
Зарплата – единственный непрозрачный момент в IT. Очень трудно транслировать, чего тебе не хватает.
Мне нравится, что у меня все сложилось так, как сложилось.
Есть одна вещь, от которой я бы мог отказаться. Моей первой full-time работой после универа был институт горного дела. Я там работал разработчиком C+, по сути – был инженером. Мы писали научные штуки, и это был очень интересный жизненный опыт. Но по факту там не было полноценной культуры разработки, не было коллег, у которых можно учиться, и на мою дальнейшую профессиональную жизнь эта работа повлияла мало.
Если бы в 2014–2015 году, когда я был Java-разработчиком в бэкенде, коллега не принес подработку под Android, моя карьера в мобильной разработке не сложилась бы. С одной стороны, это было бы грустно. С другой, я не знаю, что было бы, если бы я остался Java-разработчиком.
Какими будут разработчики через 10 лет?
Условие. Вы пошли на мобильную конференцию, но ошиблись зданием и случайно попали на форум HR. На стенде партнеров проводится конкурс визионеров: нужно предположить, как будет выглядеть типичная вакансия на Senior iOS / Android Developer в крупную продуктовую компанию через пять лет. Приз соблазнительный, поэтому вы решили прикинуться HR и тоже поучаствовать. Что напишите?
Если в вакансии есть слово Senior, про технологии там будет мало. Senior-инженер – это специалист, который умеет решать задачи. Стек он подберет сам. Поэтому, видя реалии продуктовой разработки, мне кажется, там будет больше про продукт, работу и ведение базы аналитики, умение валидировать и формулировать гипотезы, проверять их, работать с customer. То есть это должен быть product с крепким инженерным mindset'ом.
Будущее за теми командами, которые, даже без выделенного специалиста-продакта, могут сами сформулировать новую технологию, так как она поможет вывести продукт на рынок. Такие команды могут сами самоорганизоваться и сделать фичу.
Это как Netflix: команда сама принимает решение, что делать, и сама отвечает за результат. Но для этого нужен именно продуктовый скилл.
Мне кажется, senior iOS разделится на несколько веток.
Первая – очень ценные эксперты. Их будут искать компании с живым легаси, которым нужно как-то функционировать.
Второй тип senior iOS – ремесленники-универсалы. Они делают продакт-менеджмент, селф-менеджмент, продуктовую аналитику. Понимают, как измерять метрики, умеют проводить тестирования.
Третий тип – инфраструктурщики. Он не только понимают iOS, но и могут настроить тулзы для UI-тестов, например. Такие инженеры уже существуют.
Будущее за кроссплатформой?
Условие. Очередная конференция и очередной круглый стол на тему кроссплатформенной разработки. Станет ли какое-либо из текущих решений стандартом в индустрии?
Я сейчас вижу два игрока: Kotlin Multiplatform и Flutter. У каждого свои плюсы и минусы. Я не могу выбрать что-то одно. У обоих есть перспектива: они хорошо развиваются, есть понятные кейсы, большое коммьюнити.
Что будет через три года, сказать очень сложно. Мобильная разработка кардинально меняется за короткое время. Да, она может остаться на месте, но эволюционно прийти в другую точку.
Кроссплатформа точно будет существовать, и я уверен, что в ближайшие пять лет этот подход не захватит мир. Нативная разработка останется как идеальное решение для привычных паттернов. Возможно, 50 % рынка останется на нативке, другая половина будет исповедовать кроссплатформенный подоход.
Если будет хорошая кроссплатформа, все будут едины. Конференции будут для всех, коммьюнити – для всех. Компании будут больше вкладывать в этот инструмент. Как результат, мы сможем меньше времени проводить на работе.
Не знаю, какая кроссплатформа победит с точки зрения value, которое получит коммьюнити. Но мне бы хотелось, чтобы этот победитель сделал как можно больше разработчиков и пользователей счастливыми. iOS-разработчикам сложно писать на Kotlin, и это чувствуется как что-то нечестное. Я их понимаю.
Какого инструмента не хватает разработчикам?
Условие. Вас похитили и привезли на необитаемый остров в компании четырех мобильных инженеров. Чтобы сбежать, нужно выполнить требование похитителей: «Выясните, какого туллинга мобильным инженерам не хватает больше всего, и реализуйте крутое решение, которое соберет кучу звездочек на гитхабе. У вас год! На соседнем острове другая команда с таким же заданием. Кто соберет больше звездочек, вернется домой». Что будете разрабатывать?
Все зависит от инженеров и их навыков. Нужно устроить брейншторм и составить дорожную карту, затем получить пул решений.
Сейчас рынок двигается в сторону упрощения. Есть общая задача для бизнеса – выпускать быстрее и дешевле. Поэтому появляются кроссплатформенные технологии, которые мы все знаем: Kotlin, Flutter, React Native. Есть заметные упрощения с точки зрения верстки / инструментов, чтобы разработчики быстрее создавали вьюшки, которые уходят на бэк, получают JSON, парсят и выводят его.
Поэтому в данном случае нужно абстрагироваться от существующих направлений и пилить в сторону глобального упрощения. Чтобы заново перепридумать все, что можно объединить: веб, мобилку, «андроид». Делать все очень простым.
Обязательно должна быть IDE'шка с drag-and-drop'ом, где можно перевести абстрактную кнопку, нажать magic button, и эта кнопка адаптируется под Android, iOS и другие платформы.
Разрабатывать чудо-IDE, которое имеет визуальный редактор с абстрактными компонентами, компиленсом под все существующие платформы.
Что нужно, чтобы сделать что-то хорошее за один год? Идея, IDE и сплоченная команда, чтобы не убить друг друга.
Я бы шел в сторону больших команд и делал что-то, чтобы крупные проекты быстро собирались, чтобы можно было комфортно писать и работать.
В этом плане на Android все чуть лучше, чем на iOS. На последнем собирать вообще нереально: там нет нормальной build-системы, нужно писать дополнительные скрипты, чтобы все это слинковать. Непонятно, стоит ли вкладываться в xCode или лучше подождать, пока его заменят на более приятное IDE.
Я бы доверился своей команде: кого что вдохновляло, пусть это и делает. У нас бы точно что-то появилось, и мы бы классно пожили на острове целый год.
Будем писать что-то с нуля для iOS-мира и форкать известные IDE, чтобы контрибьютить в них.
