4 мая 2017
Для кого и для чего нужны еженедельные прошивки MIUI
Андрей Подкин
Мне часто приходится слышать мнение, что еженедельные прошивки MIUI — это признак низкого качества ПО. Дескать, делают все время так плохо, что приходится оперативно исправлять. Так ли это? (Спойлер: нет)
Давайте попробуем рассмотреть этот вопрос подробно. Для этого придется углубиться в технологии разработки.
Когда деревья были большими…
… а трава зеленее, чем сейчас, единственной методологией разработки программного обеспечения (ПО) был «водопад». Последовательно происходили следующие стадии:
- анализ (что нужно сделать);
- проектирование (как это сделать);
- разработка;
- тестирование;
- передача в поддержку.
Фатальным недостатком этой технологии был экспоненциальный рост стоимости ошибки в зависимости от времени между ее внесением и обнаружением. Если ошибки, допущенные при разработке, можно исправить достаточно быстро, то ошибки, допущенные при анализе или проектировании, могут привести к тому, что конечный результат будет очень далеко от цели (сделали не то, что нужно, или не так, как нужно) и потребуется переделывать все «с нуля». Возможно, это не страшно при разработке ПО для «оборонки», медицины или АЭС (там гораздо больше требований к надежности), но для типичного ПО (даже рабочего, не говоря уже про домашнее) это совершенно неприемлемо. Бизнес хочет получить результат как можно быстрее.
Больше гибкости
Поэтому со временем стали появляться гибкие методологии разработки (agile). Основной их посыл — двигаться к конечной цели постепенно, небольшими шагами. При разработке настольного или серверного ПО каждый шаг (его еще называют итерацией) обычно занимает от двух до четырех недель. После окончания итерации необходимо оценить, все ли мы правильно делаем. Если нет — надо скорректировать план дальнейшей разработки. В мобильных системах задачи зачастую меньше, поэтому итерации можно делать по одной неделе. Впрочем, недельные итерации бывают и в «больших» системах. Одной из самых ярких среди гибких методологий разработки ПО является экстремальное программирование. Свое название эта методология получила от того, что были взяты некоторые практики, считающиеся хорошими, и доведены до экстремального состояния. Например, короткие итерации — это хорошо, значит надо сделать итерации экстремально короткими — всего по одной неделе.
Разумеется, гибкие методологии работают только при вовлеченности заказчика в процесс разработки (если для заказной разработки всегда понятно, кто заказчик, то в продуктовой разработке обычно выделяется специальный человек, который отвечает за развитие продукта). По окончании каждой итерации заказчик получает промежуточную версию ПО и оценивает, насколько она соответствует его видению по развитию продукта. Если что-то идет не так, то он указывает на это разработчикам. Если вдруг его видение поменялось, то он тоже легко может повернуть разработчиков в другую сторону.
Следует обязательно помнить, что промежуточные версии не предназначены для использования конечными пользователями ПО. Это не законченный продукт, и он может создать превратное представление о том, каким будет итоговый результат.
Платформы и разные уровни разработки
Отойдем немного в сторону от методологий разработки и рассмотрим типы ПО. Из всего множества классификаций нас интересует только одна. В ее рамках все ПО делится на следующие виды:
- Конечный продукт. Разработчики — создают. Пользователи — пользуются. Никакой третьей стороны здесь нет.
- Платформа. Системные разработчики создают один продукт. На его базе прикладные разработчики создают другой продукт. Конечные пользователи используют оба продукта.
Очевидно, что любая операционная система является платформой. Прикладные разработчики создают приложения под операционную систему.
И тут у системных разработчиков появляется следующая проблема: к моменту выхода релиза (финальной версии) платформы все прикладное ПО должно быть, как минимум, совместимо с новой версией, а как максимум, должно уметь использовать все ее новые возможности.
Поэтому разработчики платформ стараются заранее выпускать предварительные версии и предоставлять их прикладным разработчикам, чтобы те могли адаптировать свое ПО. Безусловно, самый богатый опыт в этой области у корпорации Microsoft. Существуют различные программы, по которой вы можете получать предварительные версии платформ (прежде всего, конечно, Windows) и тестировать на них свои продукты. Точно так же сегодня поступают Apple и Google: они проводят для разработчиков конференции WWDC и Google I/O, на которых рассказывают о нововведениях в своих ОС. И, конечно, они в течение нескольких месяцев предоставляют предварительные версии своих ОС для того, чтобы прикладные разработчики могли успеть адаптировать свое ПО.
Нездоровый ажиотаж
В последнее время сложилась довольно странная ситуация: Apple и Google выпускают предварительные версии платформ для разработчиков, а освещение этого в СМИ происходит так, будто представляются продукты для конечных пользователей. И пользователи начинают подхватывать этот нездоровый ажиотаж и раздувать его: «Как, этот смартфон выпущен сегодня на устаревшей версии Android 7? Но ведь уже вчера Google представила Android O». Да, представила. Вчера. Первую предварительную версию, предназначенную для прикладных разработчиков, но никак не для конечных пользователей.
Так что же такое еженедельные прошивки?
А теперь складываем итерационную разработку и предварительные версии ПО и получаем еженедельные прошивки MIUI. Для кого они выпускаются?
- Для тестировщиков. Вы хотите помочь Xiaomi с открытым тестированием их прошивок и готовы отправлять отчеты? Тогда устанавливайте еженедельные прошивки и тестируйте их.
- Для разработчиков прикладного ПО. Вы хотите гарантировать своим пользователям, что ваше прикладное ПО не сломается на новой версии MIUI? Тогда тоже смело ставьте еженедельные прошивки и проверяйте на них свои приложения. Однажды я разрабатывал приложение под MIUI, которое интегрировалось со штатной «звонилкой» оболочки. При разработке я использовал два смартфона. На одном была установлена стабильная версия MIUI 7, которая соответствовала системе у заказчика. На втором я каждую неделю устанавливал еженедельные прошивки только-только появившейся тогда MIUI 8. Это давало гарантию, что при выходе окончательной версии MIUI 8 и ее установке у заказчика мое приложение продолжит работать.
Но если вы рядовой пользователь, то еженедельные прошивки не имеют для вас никакого смысла. Они не являются законченным продуктом и не предназначены для обычного использования. Для вас предназначены стабильные прошивки, которые выходят реже и тестируются тщательнее.
А как же качество?
Теперь можно ответить на исходный вопрос: говорит ли наличие еженедельных прошивок о плохом качестве MIUI? Нет не говорит. Так же, как не говорит и о хорошем. Понятие качества лежит вообще в другой плоскости и оценивается по другим критериям.
Раньше это называлось бетатестированием. Выкладывали программулину с каментом «Ребята, там всё будет глючить, но вы держитесь!»
Xiaomi их так и называет.
у сяоми есть еще ночнушки, которые собираются только для внутреннего тестирования, а комьюнити видит только пятничные релизы.
знаю. Но это не отменяет то, что публичные еженедельные — беты.
Еженедельные прошивки — это не беты, а, скорее, nightly-сборки
Единственный крупный баг в еженедельной прошивке я словил, когда загрузка новых приложений из плэймаркета не осуществлялась. Баг был две недели, потом его убрали.
У меня на еженедельной прошивке стабильно уведомления приходят, в отличии от стабильной версии
а у меня за ночь тел засыпает и при включении, уведомления, приходят все разом. Хз куда копать.
Если не пользуетесь мобильным интернетом, возможно, дело в настройках wi fi. Он может выключаться при переходе аппарата в «спящий режим». Проверьте настройки.
мобильный есть. возможно это doze так работает, но миюи нет его настроек.
У вас аппарат от xiaomi? Вот это проверьте, если так.
https://uploads.disquscdn.com/images/b492c8b3cc6b3b05771f7629aceeb077298fc51edb415c0256279f6414a4b1d8.png
посмотрим что будет утром
Наличием/отсутствием уведомлений от приложений так же можно управлять в пункте меню «безопасность»…
А у меня и на стабильной 8.2.3 все уведомления ходят как надо.
Agile и всякие спрэн митинги хороши для небольших проектов или проекта находящегося в одной плоскости…но вот когда этот недобитый тип разработки пытаются натянуть на большие проекты а лучше на 3-4 проекта завязанных друг на друге и все это пытаются представить одним проектом ….постоянные 2х недельные исправления концепций и архитектуры проекта (потому что клиент или того хуже прожекты не знают что хотят) вот тогда это ад для разработчиков бесконечное переписывание старого кода, изменение структуры баз данных, это выливается как раз в бесконечный багфикс и в реальности проекты топчется на месте и вот тогда вспоминаешь о старом добром водопаде, и так хочется сказать — дебилы вы решите что вы хотите, разработаем структуру и потом вам напишем намного быстрей…. Но случаи как всегда отличаются в деталях но пока работающий agile без мозготрахства я видел только на бумаге и в презентациях, причем громче всех это продвигает именно agile и Microsoft их ТFS с обвесами прямо заточен под это 🙂
>> но вот когда этот недобитый тип разработки пытаются натянуть на большие проекты а лучше на 3-4 проекта завязанных друг на друге и все это пытаются представить одним проектом
Есть же Agile Unified Process (адаптация Rational Unified Process), как раз для больших и сложных проектов, если непременно хочется agile попробовать.
>> потому что клиент или того хуже прожекты не знают что хотят
Тогда это и есть главная проблема 🙂
>> пока работающий agile без мозготрахства я видел только на бумаге и в презентациях
Успешный agile в проектах «сделай с нуля» для размеров, начиная от среднего, я видел тогда, когда концепция была известна заранее и вся гибкость использовалась только для контроля, а не для изменения направления разработки.
Прямо сейчас я работаю фактически по Канбану, когда уже есть какая-то стабильная версия и заказчик накидывает новые «фичи», еженедельно меняя приоритеты.
вот я про это, про концепцию 🙂 а не когда концепция «нам срочно нужен ништячёк», а потом хотелки не вида «хочу такой же только с перламутровыми, или давайте ей рукав на спигу пришьем, все равно рукава остались….», а что то типа «нет, все плохо, давайте штанины к воротнику пришьем и пусть она как брюки их носит, и хрен с ней что рукава остались сделаем это фичей…» и так далее вот тогда наступает колапс
Agile Aglie’у рознь. Это инструмент — если его применять неправильно, он и мелкий проект легко похоронит.
А так — у нас большой проект, миллионы строк кода (буквально) — и ничего, уже много лет Agile.
дело не в количестве строк, а в инфраструктуре и разношерстности подпроектов, я говорил о ситуации когда очень много подпроектов собирают в один, и пытаются им управлять, причем как только мы все побастовали и разбилист нормально на подпроекты стало легче, но ведь так и тянет же всех обозваться суперпроектом и никакой метод разработки не спасет от идиотского управления проектами 🙁
Само по себе объединение подпроектов в проект не несет ничего плохого, если эти подпроекты друг от друга зависят. Единственная серьёзная проблема, которую я встречал — это урезание бонусов за весь проект, когда провалился «чужой» подпроект. Т.е. ты вроде и молодец — сделал всё в срок и с хорошим качеством, но бонус тебе порезали вместе с теми, кто всё завалил. А в ходе разработки к нам никто особо не лез, только координировали, когда мы будем отдавать прикладным разработчикам альфа- и бета-версии платформы.
а когда проекты объединяют то все разработчики тоже объединяются и бонусы тоже. По любым проектам можно найти точки обьединения, но даже если они зависят друг от друга у них может быть разный объем работы, разные сроки исполнения, да даже казалосьбы один проект при объединении может потребовать смену реализаций или интерфеса… а я еще на своей практике не встречал чтобы сроки выставлялись по самому большому подпроекту, обычно режут под самый маленький и потом комманда дружно ненавидит разрабочиков малого подпроекта …
повторюсь, в идеале на бумаге все такое красивое и легкое…. а реальность разбивается об людей
>> По любым проектам можно найти точки обьединения, но даже если они зависят друг от друга у них может быть разный объем работы, разные сроки исполнения, да даже казалосьбы один проект при объединении может потребовать смену реализаций или интерфеса…
Тут все же правильнее смотреть с точки зрения бизнеса: если заказчик получает один комплект ПО целиком, то логично делать один проект.
>> а я еще на своей практике не встречал чтобы сроки выставлялись по самому большому подпроекту, обычно режут под самый маленький
Вот никогда не сталкивался с такой дикостью. Обычно всегда рисовалась диаграмма Ганта. Т.е. не просто сроки выставлялись по самому большому подпроекту, но еще и учитывалось, когда какой подпроект сможет стартовать (получив себе результат другого подпроекта).
будуте моим начальником? :))
А у вас там не так?
https://twitter.com/glorphindale/status/860416179470512128
:)))) нет
Ну… 430 проектов на 5 разных языках в рамках одного master solution
ТФС — то ещё гуано, согласен. Но у нас в конторе идёт разработка по Аджайлу, примерно, десяти больших банковских систем, которые взаимодействуют друг с другом, и скоро начнётся разработча системы обработки быгдаты. И всё, как ни странно, развивается, а не топчется на месте. Просто надо грамотную роудмап строить.
Спасибо за статью, правильно про релиз для разработчиков сказано
Инфографика у статьи мутная, даже стрёмная, словно рисовал какой-то распоясавшийся эффективный менеджер.
Спасибо, годно.
Мяу — луДший ведеркин форк!
Осторожнее, адепты прочих осей и ведрообразий могут не согласиться))) Ну а я с вами согласен;)
С этими недельками странная ситуация. Почему-то некоторые ромоделы пилят ромы на недельках, полностью игнорируя стабилки. Ну или делая одну стабилку из десятка.
А вообще, в гиковской среде младшего школьного возраста бытует так же альтернативное мнение, что прошивая ночнушки, недельки, или еще какие-то тестовые прошивки, прошивальщик получает самое современное, находящееся на пике мысли ПО, а не забагованную промежуточную прошивку для разработчиков, не предназначенную для ежедневного потребления.
И пес с ним, что все лагает, а звонилка вылетает раз из двух. За то вот этой классной функции по настройке сетки лончера в стабилке нет!
>> Почему-то некоторые ромоделы пилят ромы на недельках, полностью игнорируя стабилки. Ну или делая одну стабилку из десятка.
Ну, это уже вопрос к ним. Xiaomi здесь ни при чем.
>> За то вот этой классной функции по настройке сетки лончера в стабилке нет!
Если ты хорошо понимаешь, что делаешь, то почему нет? Например, я сознательно ставил девелоперку MIUI v5 (или v6, не помню уже) ради Zero Shutter Lag в камере. На тот момент разница в скорости съемки была просто разительная.
>>>Ну, это уже вопрос к ним. Xiaomi здесь ни при чем.
Понятное дело) Просто наблюдение.
>>>Если ты хорошо понимаешь, что делаешь, то почему нет?
Потому что я этими прошвками пытался пользоваться ради интереса)
Это было невозможно X)
Но правда, в данном случае речь не о сяоми и не о миуи, что не суть.
Стабилизация прошивки достаточно длительный процесс. Надо заморозить разработку, провести несколько итераций тестов и править ошибки.
В итоге пользователь увидит пару новых фич в месяц. При этом большинство пользователей используют систему процентов на 20. И стабильность остальных 80 им не очень важна.
Имеем два варианта развития событий:.
1. Стабильная прошивка 1. раз в месяц с двумя фичами. За два месяца 4 фичи.
2. 5 нестабильных прошивок с 10 фичами в месяц. И одна стабилизированная. За два месяца 20 фич. При этом часть пользователей сможет пользоваться и нестабильными версиями.
Плюс за время использования нестабильных прошивок ими пользуется достаточно большое количество народа, ловя нетривиальные баги (о которых разработчикам приходят репорты), что в итоге помогает сделать стабильные версии второго варианта гораздо больше.
Да речь-то не о том в моем комменте. Просто есть ромоделы, которые почему-то адаптируют тот же ром миуи су только в виде ночнушек. А стабилки игнорят.
» Стабильная прошивка 1. раз в месяц с двумя фичами.»
Месяц — это ещё хорошо. На некоторые аппараты стабильных прошивок годами не бывает, только ночнушки.
Действительно, разработчики предупреждают о «сырости» девелоперских сборок. Когда мобильная винда была еще жива, «игрался» со сборками десятки для Lumia 625H (для нее, кстати, офф. сборка впоследствии так и не вышла…). На сайте прямо предупреждали, что не стоит ставить такие сборки на аппараты, которые используются повседневно. И действительно, элементарные функции не работали))
Многие не внимают предупреждениям, ведь вышло же что то новое, значит нужно обязательно пробовать!) И делают потом большие глаза…
Закончилось студенчество и закончились мои оранжевые пятницы. Теперь сижу на стабилках, при чем даже не всегда на актуальных версиях.
Я даже залогинился, что бы поставить Вашему коменту +1.
Интересно конечно. Но взаимосвязь между началом и концом не могу уловить.
1) есть водопад
2) есть эджайл
3) есть ночнушки, которые нужны, что бы программы сторонних разрабов работали на новой версии стабилки ко времени ее релиза.
Я, как домохозяйка, так понял, что при «водопаде» ночнушки под жестким запретом, их можно мутить только если работаешь по эджайл. Так чтоль?:)
>> есть ночнушки, которые нужны, что бы программы сторонних разрабов работали на новой версии стабилки ко времени ее релиза.
Нет. У MIUI не «ночнушки» — это вообще отдельная тема (даже для agile), а еженедельные сборки.
>> при «водопаде» ночнушки под жестким запретом
Если совсем по-простому, то да. Предположим, разработка новой версии идет три месяца (все числа очень условные). В первый месяц нет вообще ничего (еще не дошли до разработки, идет анализ и проектирование). Второй месяц есть код, который можно собрать и отдать вам, но это совсем никто не тестировал внутри компании-разработчика. Оно может тупо падать и вы даже посмотреть не сможете. Третий месяц идет собственно тестирование внутри и в итоге вам выдают стабильную версию.
При гибкой методологии вам каждую неделю выдают то, что спроектировано, сделано и протестировано (пусть не финальным образом, но хоть как-то) в течение недели. И это действительно можно посмотреть.
Под MIUI конкретно кто-то тестируется ?
Мне искренно жаль людей, не держащихся подальше от этого глюкала…
И, да-уж лучше пара «known bugs» в оригинальной версии от Гугла, чем мегатонны новых глючков в каждом новом обновлении от китайских низкоквалифицированных «программистов оболочек»
>> Под MIUI конкретно кто-то тестируется ?
В статье даже есть пример 🙂
Вы не правы и очень предвзяты.
Почему у тебя такой ник?)
Я многие ники перебрал на этом сайте. Моих заблокированных аккаунтов несчётное количество, среди них, например, n.zh с номерами, всякие там Ctulhu триединые и четыреждыединые и многие-многие прочие, которых я даже и не вспомню. Был даже ник, который был моими настоящими именем и фамилией. А когда закончились все привычные мне ники и моя фантазия исчерпалась, я решил взять столь близкий мне, как итешнику, никнейм в оригинальном написании. В общем, выражаясь кратко — это первое, что подвернулось мне под руку. 😉
Честно признаюсь: не читал, но одобряю 🙂 Андрей, здорово, что от вас тоже есть материалы. Приятно читать ваши комментарии к статьям, и приятно видеть от вас шаг на ступеньку выше (если было и раньше, пардон заранее). Так держать!
Спасибо!
Очень нужная статья, а то пишут на форумах не весть что про «улучшения каждую неделю».
Андрей, по поводу сборок MIUI 8.X у меня пара вопросов. Но немного предыстории. 3 месяца назад я стал владельцем Redmi 4 Prime, заказывал из Китая. Аппарат пришел оригинальный (я проверял), но с прошивкой т.н. «вьетнамкой» 8.0.5.0.0. Скачал глобалку 8.1.2.0 (крайняя версия на тот момент) установил через меню телефона (3 точки), решил пользоваться оф. стоком, без разблокировки загрузчика, без получения рут-прав и установки сторонних рекавери. Через какое то время аппарат сам благополучно обновился по воздуху на глобалку 8.2.1.0. «Ура» — подумал я. Оф. обновы через ОТА работают». Совсем недавно прилетело предложение обновиться на глобалку 8.2.4.0. Скачался файл прошивки весом около 1.5 Гб, аппарат перезагрузился и…Ничего не произошло. Появилось уведомление об ошибке обновления и предложение обновиться снова. И, что самое интересное, никак не удавалось сбросить настройки аппарата к заводским, после перезагрузки снова ничего не происходило. Исходя из вышесказанного, вопрос — есть соображения, почему все было так? Везде ругали 8.2.1.0, мол, кривая и все такое, но я вообще никаких проблем не замечал, кроме невозможности обновиться дальше. А стоять на месте в безысходности не хотелось. Сейчас уже есть способ обновиться до 8.2.4.0 через MiFlash, но я решил, что не время бросать пользоваться кастомами, тем более что для моей модели их уже предостаточно)) К тому же нашел способ на форумах установить в аппарат TWRP без официальной разблокировки загрузчика. Жажда исследований победила, пользоваться оф. стоком бывает иногда откровенно скучно…
В общем, установил прошивку от MultiRom. Но столкнулся с проблемкой.. Я использую веб-сервис Disqus для обмена комментариями на различных интернет-ресурсах, в том числе и здесь.
Уведомления о полученных новых ответах на мои комментарии приходят ко мне на почту через мобильное приложение mail.ru. Раньше, при использовании глобальной версии прошивки, я мог ответить на сообщение, нажав непосредственно на конпку Reply прямо из почтового приложения (см. скриншот 1), что для меня являлось очень удобным способом. На мультироме привычная процедура приводила вот к чему (см. скриншот 2). Пробовал установить другой браузер, так же не работает, выдает ошибку подключения к интернету. Вообще темный лес…Авторы пока молчат, спросили только насчет блокировки рекламы и рут прав. Ничего этого не было. Решил уточнить здесь, может есть какие мысли? Сейчас прошился на MIUI Russia (8.1.4.0), проблем вообще никаких, все работает… https://uploads.disquscdn.com/images/b68be974340cec84204db2f74683659f0b4fc15936c63494f3098ae1d43e3295.png
https://uploads.disquscdn.com/images/72ca2e5c8ee1f3601d3ac0b6db9f25e20d5641da7d3d489257a14eb3ba06b47e.png
1. По поводу обновления не в курсе.
2. У multirom встроен файл hosts для блокировки рекламы. Там прописана строка
127.0.0.1 redirect.viglink.com
Соответственно, такие адреса не обрабатываются и из дискаса ничего не открывается (например, ссылки из комментариев).
У Miui Russia тоже встроен, однако все работает…
Не смотрел hosts у miui.su. У multirom заглянул — именно этот хост прописан.
У вас изначально лишний ноль в прошивке, а это вьетнамка
Вы это к чему?) Изначально да, была вьетнамка, я так и написал. И что?
Хочу немного дополнить Андрея. В той компании, где я работаю, используется практика Agile + Scrum. Согласно этой методике у нас короткими спринтами идёт и в том числе и развитие конечного продукта, которым пользуется заказчик. То бишь, каждые две недели у нас обновляется боевой контур — на него ставятся новые оттестированные фичи.
Сорри за оффтоп…
https://uploads.disquscdn.com/images/eacec519b4bd3b4eee874bdcf0e33fda1c61d5c85e99b60e61faab956e30d534.jpg
Не было и не будет никогда игр лучше, чем эта….