Как стать востребованным мобильным разработчиком

Мобильный разработчик (Flutter/Native) TAGES Данил Абдрафиков специально для редакции tproger.ru рассказывает о том, какими навыками и качествами должен обладать мобильный разработчик, чтобы стать востребованным.

Разработка мобильных приложений, хоть и базируется на стандартных принципах разработки ПО, но все-таки имеет свои особенности. Во-первых, такая разработка может отличаться в зависимости от конкретной платформы — Android или iOS. Во-вторых, каждая из этих платформ имеет — первая гораздо больше — определенное разнообразие устройств с индивидуальными параметрами и характеристиками: размер и разрешение экрана, тип и мощность процессора, объем оперативной памяти, наличие тех или иных датчиков и так далее.

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

Так как разработка ПО — это командная работа с итерациями, востребованному мобильному разработчику понадобятся и соответствующие надпрофессиональные (гибкие) навыки: тайм-менеджмент, коммуникативность, организованность, ответственность и др.

Исходя из личной практики, найти общий язык для успешной командной работы помогут следующие подходы:

1. Активное участие в выстраивании коммуникации в команде. Проведение и участие в «статусах» и «дейликах» помогают сохранению и актуализации контекста. Без этого продуктивная работа невозможна.
2. Регулярная демонстрация коллегам по команде результатов своей работы. Следует внимательно относиться к получаемой обратной связи и не бояться конструктивно отстаивать свою точку зрения. Это может происходить как в рамках регулярных мероприятий, так и в рамках отдельного демо, если присутствует необходимость в более глубоком погружении коллег.
3. Вовлечение команды в разработку и обсуждение идей. Особенно это касается этапа аналитики, когда можно вовремя предложить: «Давайте сделаем вот так, потому что это позволит достигнуть цели в бизнес-фиче и упростит ее реализацию (сделает ее более доступной)». Важно проводить мозговые штурмы, как говорится, подумать друг об друга — хотя бы ради того, чтобы команда смогла предложить для обсуждения неочевидные подходы к решению актуальных вопросов.
4. Наконец, понимание важности командной ретроспективы. Она помогает понять имеющиеся проблемы и составить план их решения.

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

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

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

Разработчик и дизайнер

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

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

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

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

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

1. Скелетоны

Скелетоны помогают создавать иллюзию мгновенного появления контента.

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

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

2. Тактильный интерфейс (Haptic UX)

Отдельного внимания заслуживает так называемый тактильный интерфейс, работу которого можно ощутить, просто держа в руке смартфон. Цель данного подхода — донесение обратной связи посредством прикосновений.

Тактильные элементы довольно важны при разработке мобильных приложений, поскольку они оставляют реальные ощущения у пользователя и позволяют:

• Интуитивно донести результат (успешный платеж, вызывающий кратковременную вибрацию).
• Предупредить об ошибке (например, при вводе неправильного пароля).
• Привлечь внимание пользователя (специальный жест, разблокирующий какую-нибудь функцию).

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

3. Набор готовых элементов дизайна (UI Kit)

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

Необходимо иметь четкую договоренность по различным состояниям. Порой возникают случаи, когда дизайнеры упускают из виду некоторые состояния на экранах. К примеру, «Загрузка», «Пустой список», «Ошибка». Разработчик должен им напомнить, что они существуют.

Помимо этого, важно соблюдать правильный нейминг в Figma. Должна быть согласованность компонентов UI Kit в Figma с реализацией мобильного UI Kit (то есть, уже со сверстанными компонентами). Иначе говоря, если в макете создали иконку, которая называется «play_mega_button_3000», то и в реализации название не должно отличаться. Главное, чтобы не оставалось вопросов, можно было легко ориентироваться по компонентам и быстро вносить в них изменения. Помимо этого, неплохо было бы иметь возможность переиспользования существующих компонентов.

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

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

Разработчик и QA-инженер

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

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

1. ГЛОНАСС/GPS

Если приложение работает с сервисами геолокации ГЛОНАСС или GPS, то в пасхалки можно вынести разную количественную информацию по тому, сколько на данный момент есть спутников, о текущей локации пользователя и т.д. То есть все необходимые для проверки работоспособности модуля данные.

2. Камера

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

3. Штрихкод/QR-код

В пасхалки можно выносить различные ML-киты, проверяющие распознавание barcode или QR-кодов.

4. База данных

Эта пасхалка позволяет видеть то, что хранится в локальной базе данных. Так можно более прозрачно понять, что записывает в себя приложение и какие данные оно отображает.

5. Набор готовых элементов дизайна

Такая пасхалка поможет (QA-инженерам и не только) проверить верстку, и посмотреть, как в итоге выглядит каждый компонент.

6. Окружение

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

7. Отладка

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

8. Логирование

Выводить на отдельный экран все, что логируется, чтобы не подключать устройство к компьютеру. Тогда любые обращения к серверу (Request) и ответы от него (Response), а также возникшие ошибки будут видны в логах. Это существенно облегчит работу QA-инженера по выявлению причин тех или иных проблем.

Востребованный мобильный разработчик — это…

Прежде всего, востребованный мобильный разработчик — это специалист, который хочет и умеет делиться своими знаниями. Данный навык относится к наставничеству (менторству). Когда у вас есть подопечные, вы не только сами растете, но и узнаете что-то новое вместе с ними.

Такой специалист, готов вникать и помогать коллегам из смежных сфер, например, дизайна или QA.

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