Добавление новых возможностей в мобильное приложение — это многоступенчатый процесс, который требует согласованности в команде. В то же время он должен быть итеративным: в больших компаниях любят термин «релизный цикл». Не так давно разработчик Яндекс.Музыки Дмитрий Трубников разобрал весь путь фичи (новой функциональности) на Mobile Junior meetup. Эта встреча собрала начинающих специалистов по Android и iOS и будущих участников [стажировки Яндекса](http://yandex.ru/yaintern/?utm_source=academy.yandex.ru%2 °F). Перед вами статья Димы, написанная по мотивам его доклада.

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

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

Команда

Сколько людей нужно, чтобы написать приложение? Каков минимальный набор ролей? Конечно, нужны разработчик и дизайнеры. Но также нужен тестировщик — человек, который следит за тем, что сделал разработчик и правильно ли он это сделал. И менеджер, который определяет вектор развития приложения: на какие части приложения мы будем делать основной упор, в какую сторону будем двигаться.

Последняя роль на самом деле наиболее важная. Без нее не может обойтись ни одно приложение.

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

Идея

Где же здесь пользователь? Чтобы это понять, нужно глобально взглянуть на задачу и подумать, а для чего вообще создаются приложения.

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

Таким образом, идеи идут от пользователей. Вопрос: а как мы о них узнаем и как реагируем? У нас может быть какой-то явный фичреквест от пользователей. Например, пользователь может написать где-нибудь в Play Market или в support, мол, я хочу кнопочку, которая запускает пятый трек снизу. Странно, но окей, мы тебя услышали.

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

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

Задача

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

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

Этот процесс можно проиллюстрировать на примере подкастов в Яндекс. Музыке. Подкасты — хайповое слово. Все сейчас слушают подкасты. Нравится, удобно. И Яндекс.Музыка не осталась в стороне. В приложении появились подкасты. Мы их уже в каком-то релизе выпустили и начали собирать первые отзывы пользователей. Они были примерно такие:

Сводились они примерно к тому, что, да, мне очень нравятся подкасты, это здорово, круто, но слушать два часа подкасты мне тяжело. Добавьте возможность увеличить скорость воспроизведения. И тут не надо быть аналитиком, чтобы стало понятно: да, действительно, фича нужная, классная. Давайте будем делать. Так появилась идея.

На примере этой фичи можно пройти до конца и понять, как она попадет на устройства пользователей.

Разработка

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

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

Код-ревью

Код-ревью — это когда коллеги-разработчики — их может быть разное количество, обычно двое — смотрят на изменения, которые вы хотите внести в общую кодовую базу. Могут дать какой-то совет. Например, вы сейчас решаете задачу, а коллеги видят, что в этой задаче хорошо бы зашел такой-то паттерн проектирования. Так будет проще и читать код, и вносить в него изменения. Почему всё это важно? Потому что то, что вы сейчас пытаетесь интегрировать в основную кодовую базу, в следующем релизе станет этой самой кодовой базой. Чем лучше вы напишете сейчас, тем проще вам будет работать потом. Подумайте о себе и о своих коллегах в будущем.

Тестирование и merge

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

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

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

Альфа-тестирование

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

Асессоры чаще всего работают удаленно и проверяют фичу с нескольких устройств. Они прогоняют все пользовательские сценарии, которые есть. В Музыке их около полутора тысяч. Зачем нужно столько людей? Наверняка вы знаете, что существуют баги, которые очень тяжело отловить, потому что какой-то очевидный баг увидит сам разработчик или его коллеги на первых этапах: во время тестирования, ревью. А есть баги, которые возникают, скажем, только по четвергам при полной фазе луны и каких-то других специфических условиях. Их довольно сложно поймать. Чем больше людей и разнообразных устройств — тем выше вероятность их найти.

Бета-тестирование

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

Здесь может возникнуть вопрос: зачем столько этапов, столько людей?

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

Говоря о версиях мобильного приложения, нельзя не упомянуть версионность. Мобильное приложение — это архив на устройствах. Разработчики не могут обновить его в произвольный момент. Есть разные типы пользователей: кто-то будет обновляться по мере появления апдейтов, кто-то останется с первой версией, кто-то сразу загрузит последнюю. Вы должны обеспечить работоспособность в каждом из этих случаев. Предположим, вы выпустили два апдейта: в одном вы добавляете таблицу, во втором удаляете её. При удалении сделайте проверку на то, существует ли эта таблица: если человек обновляется с более старых версий, где её нет, то приложение упадёт.

Итак, альфа- и бета-тестирование прошло, выкатываемся в Play Market или в App Store. После этого наш релизный цикл начинается заново, на то он и цикл:

Выводы

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

2. Делая новое, не ломай старое. Когда вы вносите изменения в код вашего приложения, помните, думайте о возможных сайд-эффектах. Все помнят гифку с котиком? На самом деле на гифке показан идеальный случай: котик что-то повернул, что-то сломал и сразу увидел сзади водопад. Чаще всего происходит не так: водопад случится, но это такая бомба замедленного действия, она сработает гораздо позже. Для этого должно выполниться много условий.

3. Вероятность бага в полпроцента — это много.

4. Ранний баг — это хорошо. Чем раньше мы его обнаружим, тем проще и дешевле нам будет его исправить.

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