Comments 5
Зачем вы пишите мобильные приложения с таким подходом? Они же у вас и выглядят 100% как кусок фекалий (поправим какие-то отступы, а ничего, что там инсеты надо обрабатывать уже, predictive back использовать). Вы за год не способны понять и донести что нужно время на обновление? 35 api вышло не вчера как бы.
Я даже боюсь представить какой вы там c/cpp код с такими подходами пишете...
Про зачем, как выглядят и все прочее. Мне кажется вы не уловили основной посыл материала - речь о том, что есть задача, есть требования по срокам. Речь совсем не о том, как мне хочется делать или не хочется, посыл в том, что делать если ситуация сложилась аналогичным образом. Не вижу у себя в тексте нигде о том, что подход рекомендован кем-либо.
Касательно донести - не знаю какие правила в вашей компании, а в нашей считают каждый рубль, потому время от времени и получаем кейс, когда хорошее решение проигрывает - более дешевому, новые фичи в приоритете относительно оптимизаций и рефакторинга, независимо от пожеланий и мнений команды разработки.
По поводу чего вы там боитесь - не бойтесь)
Мой опыт:
— 3 древних проекта, куча модулей, deprecated-код, а заказчик говорит: «Это же просто цифры поменять, да?»
— Android SDK Update Assistant? Смешно. Пришлось вручную ковыряться в граблах, как археолог в руинах.
Какой из этого вывод
Google хочет, чтобы все приложения были современными, но забывает, что половина кода в индустрии — легаси на грани археологии. Бизнес не хочет тратить время на апдейты, пока Google не пригрозит баном. Разработчики сидят с if (SDK_INT > UPSIDE_DOWN_CAKE) и мечтают о переписывании всего с нуля.
а, List.getFirst(), уже классическая подстава от Kotlin. Хорошо, что она описана в официальных гайдах по обновлению, есть в youtrack jetbrains.
Android обновление API SDK до 35 версии в сжатые сроки, в большом легаси-проекте