КДПВ не будет, извиняйте. Значение имеют только текст, тесты и статистика :)

Сам термин Statistics Driven Development (сокращенно SDD) я ввел в my.games году в 2017м, но среди очень небольшого количества людей и до сих пор не встречал его в статьях. Самому мне было лень писать куда-то, кроме чатиков. Увы.

Возможно, этот подход давно существует и просто я не в курсе. Скажите, плиз, если это так.

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

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

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

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

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

В моей практике хорошо зарекомендовал себя подход, когда ключевые места в коде отправляют в базу статистики деперсонализированные данные, а на сервере выполняются проверки, соответствуют ли пришедшие данные ожиданиям. Проверки выполняются как вручную, так и с помощью SQL запросов и отдельных скриптов. Разброс интервалов cron-проверок в проектах, где я участвовал, составлял от 5 минут до 4 часов - в зависимости от объемов данных. Чем больше данных приходит за минуту, тем меньше можно делать интервал проверки, чтобы минимизировать вероятность случайных выбросов.

В реализации, использующейся в Игровом центре my.games, запаздывание между отправкой данных клиентом и размещением их в БД в пригодном для анализа виде составляло около 90 секунд. Это время легко сократить в разы, но на практике оказалось, что и 90-секундное отставания комфортно для очень быстрых итераций "тестировщик увидел ошибку - разработчик сразу же посмотрел по базе детали того, что случилось".

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

Кроме ручных проверок по базе выполнялись, например, такие тесты (числовые показатели пишу условно - они в данном случае не принципиальны):

• количество исключений в проекте для последней зарелизенной версии за последние 10 минут не больше 2% от количества запусков;

• количество установок каждой из ключевых игр за последние 30 минут составляет не менее 50% от количества, которое было час назад и не менее 70% от того, что было сутки и неделю назад;

• push-уведомления дошли до пользователя не позднее 20 секунд с момента отправки серверным кодом не менее чем в 80% случаев и не позднее 1 минуты не менее чем в 90% случаев.

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

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

(в каком месте проценты упали до нуля - там и надо искать проблему)

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

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

Ключевые выигрыши от подхода SDD следующие:

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

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

3. При проблемах в проде источник проблемы детектится за несколько минут. Автоматически или ручками, запросами к базе - в зависимости от того, насколько подходящими оказались автоматические тесты для возникшей проблемы. Меньше фрустрации.

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

Если интересно, могу написать продолжение о том, как всё это внедрялось.