Оценки

Никогда такого не было, и вот опять! Опять на прошлой неделе на Хабре появился (и был очень активно комментирован) пост, ныне удалённый, о том, что такое хороший код и чем он отличается от плохого. Яндекс подсказывает, что публикаций о хорошем (вариант: отличном, идеальном, правильном, чистом, грязном, плохом и т.д.) коде здесь уже десятки и сотни, появляются они стабильно на протяжении многих лет, всегда активно обсуждаются, но к единому мнению на этот счёт так и не пришли.

Моё мнение - нет никакого "хорошего кода", потому что само понятие "хороший" крайне субъективно и неизмеримо. Так, может, нужна линейка для измерения хорошести качества кода? В общем, предлагаю вашему вниманию шкалу из 5 значений (ну или 6, начиная с нулевого - мыжпрограммисты), а для наглядности они обозначены звёздами. Впрочем, вы можете заменить звёзды на даны, школьные баллы, попугаи или любые другие единицы измерения - суть не изменится. Погнали!

0 звёзд - неработоспособный код

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

Одна звезда - минимально работоспособный код

Код, который успешно исполняется и при этом исполняет требования рабочего задания. Вот и всё. Дальнейшие оценки его качества - оптимизация, читаемость и тому подобное - в рамки этого уровня качества не вписываются. От однозвёздочного кода требуется просто работать, вот и ладно.

Такой код в настоящее время распространён повсеместно. Причин этому несколько, вот наиболее заметные:

• Аппаратный прогресс: рост вычислительных мощностей, удешевление памяти. Кажется, что программы незачем оптимизировать - ведь и так будет летать, эти восемь ядер всё сожрут!

• Массовая цифровизация, из-за которой техзадания программистам ставят люди, далёкие от IT (например, руководители заводов) и они в принципе не могут оценить качество кода.

• Высокие зарплаты в IT активно привлекают всех-всех-всех, которые трудоустраиваются, пройдя курсы "вайти-вайти за месяц" и имея соответствующие навыки.

• Высокие зарплаты в IT стимулируют экономию со стороны руководителей - они нанимают тех, кто готов работать за минимальные деньги (прямиком из предыдущего пункта).

Справедливости ради: не всегда это плохо. Если разработка маломасштабная, то её и оптимизировать особо незачем (и так летать будет, ну ведь правда же!). Так или иначе, такой код обычно пишут начинающие программисты и по мере обретения опыта переходят на уровень выше.

Две звезды - быстрый код

Код, который не просто работает, но ещё и работает достаточно быстро. Можно сказать, что этот код оптимизирован по процессорной вычислительной мощности. Одно из формальных определений:

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

На практике эффективность по времени иногда определяется не по этому учебно-тренировочному критерию, а по объективным целям и задачам проекта, и может быть задана как относительно ("на каждый N не больше k"), так и абсолютно ("открывать окно не дольше 0,5 секунды") или даже субъективно ("не менее 80% опрошенных согласились, что программа открывается мгновенно").

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

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

Три звезды - оптимизированный код

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

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

Создание такого кода - признак определённого мастерства.

Четыре звезды - компактный код

Код, который сам имеет минимальный объём. Можно сказать, что он оптимизирован и по процессору, и по оперативке, и по накопителю.

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

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

Пять звёзд - идеальный код

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

Выводы

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

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

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

Googleпредложилсвое решениеэтой проблемыупростить сценарий выставления оценки при помощиIn-App-Review.

Мы в Кошельке поставили перед собой задачу увеличить количество положительных оценок приложения, используя новое API. Для этого мы изучили его, интегрировали в свой продукти провели ряд показательных тестов в попыткахнайтилучшее решение.Результаты нас порадовали. Если заинтересовались прошу под кат.

Пара слов об интеграции

Ключевая особенностьIn-App-Reviewзаключается в том, что пользователю не нужно покидать приложениеи переходить в маркет, чтобы оценить его. Все,что ему надо сделать это выбрать нужное количество звезд в появившемся на экране диалоге, ивуаляоценка поставлена, юзер и разработчик счастливы!

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

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

2. Из первого пункта вытекает вопрос: а как тестировать? Этот вопрос также довольно неплохо описанв доке,к нему мы вернемся чуть позже;

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

Что не так сколбэками?

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

1. ВызовметодаrequestReviewFlow

   

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

   Почему операция может завершиться неудачно? К примеру, если вашеприложение запущено на устройствеHuaweiбезPlay-сервисов, то получениеобъектаReviewInfoзавершится с ошибкой, и вы сможете в этом случае перенаправить пользователя вAppGallery.

2. Непосредственно запускрейтинговалки вызовметодаlaunchReviewFlow

   

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

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

И чуть-чуть о тестировании

Как уже было сказано выше, протестировать появление диалога можно лишь на сборке изPlayMarket. Чтобы это сделать,Googleпредлагает два способа:

1. Internaltesttrack: создаемтестовую версию вPlayConsole, загружаем тудаapk-файл с реализацией API, затем формируемсписок тестировщиков, которым эта версия будет доступна для скачивания. После этого ждем, пока версия будет доступна для скачивания вPlayMarket;

2. Internalappsharing:это что-то вроде тестового полигона, который позволяет сделать то же самое, что и способ, описанный выше, но при этом пропустить некоторые шаги, которые занимают много времени(тем самым освободив разработчиков и тестировщиков от необходимости дожидаться доступности сборки для скачивания).

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

Отправили сборку вPlayMarketи стали ждать, пока новая версия будет доступна для скачивания. И вот, спустя несколько часов, мы увидели долгожданный диалог:

Note:если в процессе тестирования вы обнаружите, что выполнили необходимые условия, а диалог не появился, дело может быть вQuotas. ВIn-App-Reviewимеютсянекоторые ограниченияна частоту показа диалога и, возможно, ещёне прошло достаточно времени с момента последнего его появления.

Вперед к экспериментам!

Теперь, когда стало ясно, как работаетIn-App-ReviewAPI, и учтены все нюансы, возникают логичные вопросы: что, если пользователь будет раздражен появившимся диалогом и решит поставить неудовлетворительную оценку? Или он ещёне успел достаточно времени провести в приложении, чтобы его оценить?

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

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

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

ДокументацияIn-App-Reviewчеткоговорит о том, что не стоит задавать пользователю вопросов, прямокасающихся его мнения о приложении.

Мы решили провести ряд своих экспериментовв поискахответа на вопрос: Стоит ли спрашивать мнение пользователя перед отображением диалога оценки приложения?.

Стартовая площадка

Перед тем, как мы запустили эксперименты, процесс сбора оценок был таким:

1. Если пользователь провёлв приложении 14 дней или больше, мы показываем емусобственныйpop-upКошелька.

2. Если в нашем диалогепользователь поставил оценку 4 или 5, отправляем его вPlayMarket.

В последние месяцы это давало следующие результаты:

Среднее количество оценок в месяц: 8 тыс.;

Среднее количество отзывов в месяц: 2.1 тыс.;

Средняя оценка: 4,54.

Для удобства дальше этот вариант будем называтьcontrol.

Эксперимент #1: с предварительным диалогом

В первом эксперименте мы решили поступить, как все, и злостно нарушили гайдлайныGoogle оставили собственный диалог, в котором предлагали пользователю поставить оценку,и,если он выбрал 4 или 5 звезд, мы запускали процесс оценки с помощьюIn-App-Review.

Назовем этот вариантin-app-review.

Мы выкатили версию приложения с этим методом оценки на 2 месяца, и вот что получилось:

• Среднее количество оценок в месяц увеличилось на 60% с8000 до 12800;

• Средняя оценка увеличилась с 4,54 до 4,67;

• Среднее количество отзывовнемного снизилось было 2100,астало 2000.

Процент пользователей,поставивших5 звезд, увеличился с 80% до 84,9%.

Общее распределение выглядит так:

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

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

Эксперимент #2: без предварительного диалога

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

Этот вариант назовемonly-in-app-review.

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

• Количество оценок в месяц выросло на 143% по сравнению с вариантомcontrolи на 52% по сравнению с первым экспериментом;

• Средняя оценка совсем немного упала по сравнению с первым экспериментом, но все равно осталась выше, чем в контрольном варианте;

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

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

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

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

Вместо вывода

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

Средняя оценка в эксперименте с предварительным показом диалога составила 4.67, без показа 4.63.Количество оценок в первом случаесоставило почти 13 тыс., во втором20 тыс. В итоге в качестве рабочего варианта мы решили выбрать вариантonly-in-app-reviewпо трём основным причинам:

1. Средние оценки в двух вариантах эксперимента практически не отличаются;

2. Этот вариант полностью соответствует гайдлайнам, описанным в документации;

3. Количество оценок значительно увеличилось.

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

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