Senior iOS-разработчик из VK: «Работа в энтерпрайзе — это стабильность»
2026-02-21 08:50 Diff

#статьи

  • 27 апр 2022
  • 0

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

Фото: Bloomberg / Getty Images

Любитель научной фантастики и технологического прогресса. Хорошо сочетает в себе заумного технаря и утончённого гуманитария. Пишет про IT и радуется этому.

Руководитель мобильной разработки в VK, бывший лид iOS в «Тинькофф». Любит писать код и вкусно готовить.

Мой путь в программировании начался шесть лет назад с первой версии языка Swift и покупки макбука. Сейчас я руковожу мобильной разработкой в VK, а до этого был мидлом в «Тинькофф» и даже отпахал два года в аутсорсе. Поэтому могу рассказать, чем работа в аутсорсе отличается от энтерпрайза и почему энтерпрайз лучше.

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

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

Руководители аутсорс-компаний строго следят за временем. Они ставят программы для отслеживания рабочего времени сотрудников, чтобы потом проще было обосновать итоговую стоимость проекта: «Вот, мои ребята потратили столько-то часов, всё честно».

Энтерпрайз-команды обычно небольшие — например, у нас в команде всего три iOS-разработчика. Хотя есть и такие продукты, над которыми работает двадцать «айосеров». Ещё в нашей команде есть Android‑разработчики, менеджеры, дизайнеры, тестировщики и бэкендеры, так что обычно приходится взаимодействовать с кучей людей.

В крупных компаниях грамотно планируют сроки и задачи для разработчиков. Этим энтерпрайз тоже положительно отличаются от аутсорса, где из-за ограничений в бюджете продукты часто делают «как получится» и выпускают сразу же по готовности.

Сейчас в iOS-разработке популярен Swift: он простой, и его продвигает Apple. Поэтому на рынке труда этот язык остаётся одним из самых востребованных. Им пользуются почти все крупные компании: «Тинькофф», VK, «Альфа-Банк» и другие. В некоторых наших проектах осталось легаси на Objective-C — на нём написаны многие сторонние библиотеки. Чтобы поддерживать несколько кодовых баз, мы используем систему контроля версий GitFlow.

Схема веток в системе контроля версий GitFlow
Источник: Atlassian

В «Тинькофф» у нас был отдельный репозиторий с общими компонентами: чатами, инструментами для сканирования документов и так далее. Кроме того, была единая дизайн-система для всех приложений — она нужна, чтобы легче шарить код в другие проекты. Этим занималась отдельная команда. В экосистеме VK много разных дизайн-систем, поэтому писать общие компоненты для всех бессмысленно.

Главная проблема нашего приложения — сложность внедрения новых технологий. И дело даже не в том, что их сложно изучать, — просто пользователи не хотят обновлять свои устройства до актуальных версий. Поэтому мы не используем SwiftUI, компоненты Combine и другие фишки iOS 13. Многие компании до сих пор сидят на iOS 12, но есть и те, кто активно использует фичи четырнадцатой версии.

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

Я работаю со стандартными библиотеками для iOS — UIkit, Foundation и Core Data. Использую их в вёрстке, сетевых взаимодействиях и других базовых вещах. Из инструментов у меня только Xcode и плагины для него: линтеры, генераторы ресурсов и другие инструменты, которые упрощают разработку. Ещё у нас есть unit‑, snapshot‑тесты и Continuous Integration (CI) — чтобы собирать проекты, доставлять их тестировщикам и в App Store.

Чтобы не писать много кода вручную, я использую OpenCombine и фреймворки для аналитики и нетворкинга. С СУБД почти не работаю, хотя в «Тинькофф» у нас были специальные библиотеки с шифрованием на SQLite, а также Core Data.

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

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

Мы работаем по принципам Agile, придерживаемся графиков и условий, чтобы понимать, кто чем занимается. У нас есть двухнедельные спринты, в конце которых мы проводим ретроспективу и обсуждаем итоги. Затем снова наступает этап планирования: мы с менеджерами смотрим в бэклог, оцениваем время и приоритет задач и ставим их в новый спринт.

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

Когда появляется баг, мы сначала оцениваем, насколько он горящий, а уже потом исправляем или откладываем его решение в соответствии с приоритетами. Обычно баги исправляем за пару дней, но есть и трудноуловимые, на которые приходится тратить много времени и ресурсов. После фикса мы отдаём код тестировщикам, а потом — на ревью Apple. Суммарно фикс бага занимает один-три дня.

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

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

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

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

Стартапы тоже хороши, но по-своему. Если у вас есть силы и желание вникать в другие сферы, кроме разработки, то вы сможете развиваться как предприниматель. Правда, иногда придётся перерабатывать.

Минусы работы в стартапе — нестабильный заработок и переработки. Плюсы — если стартап выстрелит, то вы получите в нём хорошую долю.

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

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

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

Кадр: фильм «Форсаж 7»

Мы на собеседованиях не смотрим на диплом, потому что важны в первую очередь технические знания программиста. Если у кандидата недостаточно опыта или нас не устраивают какие-то его качества, то мы его не берём. И неважно, есть у него диплом или нет.

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

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

Кроме того, у многих разработчиков рано или поздно возникает желание «выйти в свет»: например, выступать на митапах и конференциях. Здесь без софт-скиллов никуда.

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

Главная цель интервью — понять, что вы знаете, а что — нет. Интервьюер «копает» вглубь, чтобы найти вопросы, на которых кандидат начнёт сомневаться или вовсе перестанет отвечать. Собеседование — это паттерн, который можно изучить только на собственном опыте. И тем не менее к ним всегда надо готовиться.

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

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

  • Twitter. В этой соцсети обитает много разработчиков, которые делятся опытом и знаниями. Например, Джон Санделл, польский программист, пишет статьи о новых технологиях и гайды для начинающих. Все они на английском, но очень интересные и полезные. Так что если у вас всё ещё нет аккаунта в Twitter, то вы многое пропускаете.
  • Telegram. Здесь есть много классных каналов про iOS-разработку. Например, iOS Good Reads или канал программистов из «Додо».
  • YouTube. Здесь полно каналов про iOS-разработку. Например, Paul Hudson, AppleProgramming и CodeWithChris.
  • Курсы. Это тоже неплохой способ освоить профессию, особенно если вам не хватает мотивации или нужен наставник. На курсах можно найти и то и другое. Но даже если вы проходите курсы, продолжайте самостоятельно программировать и читать дополнительные источники.

Если говорить про технологии, то начинающим iOS-разработчикам я рекомендую изучать UIKit, а не SwiftUI. Потому что UIKit — это основа, поверх которой работает SwiftUI, и на UIKit написано большинство приложений под iOS.

Тем, кто переходит в iOS-разработку с другого стека, я советую взять курс, чтобы не тратить время. Подойдут и бесплатные уроки на YouTube или, например, курсы Стэнфорда. Главное — чтобы вы были достаточно мотивированы.

Не бойтесь писать свои проекты, и не надо SwiftUI. Пожалуйста :)

В мобильной разработке мне нравится ощущать причастность к чему-то масштабному. Моими приложениями пользуются люди, а результат работы виден сразу же. Это приятно.

Своим проектам я уделяю мало времени. Но уж если я сажусь писать что-то, то обычно это связано с новыми для меня технологиями и инструментами. Например, я никогда не работал с 3D-графикой напрямую и никогда не рендерил треугольники и полигоны на экране. Мне стало интересно. Я скачал книгу и начал делать проект, который в дальнейшем может вырасти во что-то интересное. Однажды я захотел разобраться, как работает dependency injection, и написал библиотеку, которая получила 100 звёзд на GitHub. Приятно? Очень!

За время удалёнки я понял, что было бы здорово устроиться в зарубежную компанию. Я думаю, главный стимул — поработать в англоязычной команде, чтобы улучшить свои знания языка. Сейчас для меня это важно.

Я бы хотел пожить в другой стране. Это был бы неплохой опыт в моей биографии. Кажется, когда человек меняет своё окружение, — это хороший опыт коммуникации и развития. Ведь когда мы к чему-то прирастаем, то развиваться становится гораздо тяжелее. То же касается и работы: если долго сидеть на одной позиции, непременно начнётся стагнация.


Бесплатный курс по Python ➞
Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу