Pull to refresh

Comments 22

На данный момент мы не можем воспроизвести ошибку, поэтому лучшая стратегия:
Откатить обратно одну из двух библиотек.Выкатить её для 10% пользователей, что тривиально делается в Play Store.Проверить у нескольких пользователей, сохранился ли сбой. Таким образом мы подтвердим или опровергнем гипотезу.

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

UFO just landed and posted this here
Эти люди разрабатывают под Android на реакте. Уже на этом месте стоило понять, что они занимаются чем-то неадекватным и практики у них будут соответствующие.
А что, вы знаете простой способ это сделать?

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

Ну-ну, ещё не забыть правильно всё откатить. Ещё бывают либы, которые не умеют. даунгредиться.

Возможно я что-то не знаю про разработку под Андроид. Я полагал, что пакет приложения заменяется целиком, это не так?


Вопрос же был не как вернусь из репозитория версию до обновления (это уж точно не должно вызвать сложностей), а как обновить у пользователей? Так вот если они предыдущую версию зальют (поставив ей версию +1) — Гугл не может это залить пользователям? У них не заведётся?

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

Зависит от библиотек, конечно, согласен. Если библиотека потребовала изменения формата внутреннего хранения (и при обновлении, например, формат сконвертировался), то это сложности. Или менеджер потребовал какую-то фичу внедрить в тот же релиз.


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

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

Ну разумеется версию нужно сменить. Это рокет сайнс что ли? Имеется ввиду, разработчик сменит, а не каждый пользователь.

Отличная иллюстративная статья про восхитительный мир фронтэнда, спасибо.

> Мы обновили 3rd-party либы и убили наше приложение для 10% юзеров
> Но всё нормально, потому что мы быстро это пофиксили, да и вообще, шо вы хотите, граждане, нонче всё так работает.

^_^
не убили. просто в 10% случаев юзеру придется открыть приложение ещё раз
Ну да, это конечно гораздо менее страшно, но посыл в общем остаётся тот же. Прям как будто возвращаешься в 90-е, где свойство некоторых программ «неожиданно падать» воспринималось довольно обыденно :-)
Но всё нормально, потому что мы быстро это пофиксили

10 дней всё длилось, судя по графику. Не быстро.

Маловероятно, тут была классическая гонка, для этого теоретически существуют специальные инструменты типа fbinfer.com/docs/racerd.html, но они не гарантируют 100% поимки подобных проблем. А уж если у вас в коде есть lockless контейнеры, то дебаг будет особенно приятным :)
ну норм. анализатор должен определять, что появилась гонка, и как-то сигнализировать по части потоконебезопасного кода.

Сразу подумал что race condition, когда дошли до значения -1 то и думать не надо дальше. Молодцы что нашли что и где конкретно, но ведь фикса могло и не существовать, а самим по запаре сделать фикс в чужую огромную кодбазу не получится, можно еще больше сломать. Надо было откатывать.

О чем статья-то? Про race condition?.. Или про то, что после обновления библиотеки надо тестить получше? Не слабовато для Хабра?
Ммм, ясно. Хочешь разрабатывать приложения на JavaScript — готовься фиксить баги в Java.
Sign up to leave a comment.

Articles