Недавно Карло Карагич, один из наших старших разработчиков Android, имел возможность посетить конференцию SuperMinds: Mind the App, где один из докладов вызвал его интерес, о котором мы расскажем позже. Давайте сначала подведем небольшой итог всех четырех докладов.

Элиза Кэмбер открыла переговоры с «Машинное обучение на Android». Это был обзор текущего состояния инструментов ML (машинного обучения) в мире Android с несколькими примерами предварительно обученных моделей, которые предоставляет Google — сканер штрих-кода, оптическое распознавание символов, преобразование речи в текст и т. д.

Следующими были Лука Леопольдович и Филип Дебелич с «Прошлое, настоящее и будущее (приложения продукта)». Это был доклад, ориентированный на разработчиков, с акцентом на инструменты и архитектуру Android. Они продемонстрировали свое многомодульное приложение, созданное с учетом командного масштабирования.

После них на сцену вышла Кристина Ли с докладом на более психологическую тематику: «Собака и технический руководитель: чему научил меня дрессировка животных, чтобы стать лучшим наставником». Это был увлекательный разговор о мягких навыках в индустрии. Презентация была посвящена тому, как позитивность и установка кого-то на успех оказывают существенное положительное влияние на процесс обучения.

И, наконец, центр этой статьи. Выступление Гаррика Тубасси. Его тема была Поставка «мобильных приложений в стартапы и большие технологии». Доклад был построен вокруг трех примеров (два стартапа и одно корпоративное приложение).

Приложения корпоративного уровня

Приложение, о котором мы говорим, — Inbox от команды Gmail. Это было одно из первых приложений, пытавшихся обеспечить единообразие работы на двух мобильных платформах и в Интернете. Это означало писать код трижды, что не очень хорошая идея (как сказал автор — Я не доверяю разработчику писать его один раз, не говоря уже о трех). В конце концов они нашли способ написать 60% приложения на Java (пользовательский интерфейс для Android и бизнес-логику для всех трех платформ) с помощью J2CL (Java в JS) и J2OBJC (Java в Objective-C). Из этого они сделали несколько выводов:

С тех пор мы прошли долгий путь, и теперь у нас есть больше, чем просто хаки для кроссплатформенной работы. Одним из таких инструментов является Kotlin Multiplatform Mobile. Несмотря на то, что он находится на невероятно ранней стадии разработки (когда мы попробовали его, мы обнаружили много причуд, которые сделали жизнь намного сложнее, чем нужно). Тем не менее, такие предприятия, как Philips, Netflix и другие, уже пытаются запустить его в производство, поскольку у этой платформы большой потенциал.

Но два абсолютных короля в этой области — Flutter и React Native. В отличие от KMM (Kotlin Multiplatform Mobile), они также обрабатывают уровень пользовательского интерфейса, и вы можете писать целые приложения на соответствующих языках. Вместе они покрывают 80% рынка мультиплатформенных фреймворков. Кстати, Flutter превзошел по популярности React Native в 2022 году.

Приложения стартового уровня

Здесь два примера: Shopstyle и Locket. Первый — это агрегатор индустрии моды, а второй — виджет для обмена фотографиями. Выводы, сделанные в результате их анализа, были слишком схожими, и поэтому мы объединим полученные данные. Выводы были такими:

  • Хороший соло-разработчик стоит больше, чем 5 сотрудников (обычно full-stack).
  • Преждевременная оптимизация не нужна и даже вредна (у Twitter было 100 миллионов пользователей с приложением Ruby on Rails, которое не славится большим масштабированием).
  • Язык также не важен — один из стартапов сделал Android-приложение на React Native, не собираясь когда-либо делать его кроссплатформенным (наверное, кто-то в то время знал JS больше, чем Kotlin/Java; или не знал о Kotlin). /JS-компилятор)
  • Еще один уровень защиты от крупных фирм заключается в том, что пользователям нравятся небольшие приложения с определенными функциями.

Самый большой вывод здесь заключается в том, что не так важно, с чем вы пишете свое потенциальное приложение на миллион долларов. Например, ржавый стек LAMP (Linux, Apache, MySQL и PHP) все еще (довольно) популярен в наши дни. С другой стороны, также вполне жизнеспособно писать приложение и в инновационных фреймворках (надеюсь, не за гранью — технология должна быть хотя бы на стадии бета-тестирования, на ум приходит Qwik).

Единственный совет, который мы могли бы предложить здесь, — придерживаться чего-то близкого к дому. Как и в приведенном примере, если вы разработчик JavaScript или React, почему бы не сделать свое мобильное приложение в React Native. Будут проблемы, но, по крайней мере, вы не будете бороться с языком и платформой.

Выводы

Мои мысли об этом — Карло Карагич

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

Конечно, это не означает, что мы должны вернуться к написанию всего нашего кода в одном файле и считать его выполненным. В середине есть сладкое пятно. В мире Android нам очень нравится придерживаться предопределенной архитектуры, учитывая, что для нашей выбранной платформы сложно разрабатывать. Таким образом, со временем мы научились уводить наш код как можно дальше от кода, специфичного для Android. Это позволяет нам иметь хорошую многослойность в кодовой базе, что позволяет нам переключать/изменять части, которые нам не нравятся или которые нуждаются в улучшении (и защищает нас от изменений в самой ОС Android). Это одна часть головоломки: сделайте наш код как можно более чистым.

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

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

Давайте не будем забывать о ваших миллионах пользователей. Давайте рассмотрим пример: в Google каждая проблема — это масштабная проблема. Подумайте об одной ошибке на миллион, которая может случиться; ошибка, которая крайне маловероятна. Для большинства из нас, разработчиков, это не проблема, но для приложения Gmail (просто пример) это критическая проблема, потенциально затрагивающая тысячи людей. Как к этому подготовиться? Как убедиться, что вы обнаруживаете и устраняете ошибки, которые большинство других пользователей могли бы просто проигнорировать?

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

Мои мысли об этом — Александр Джесс

Встать и бежать быстро — это ключ, но с некоторыми оговорками, которые всегда нужно держать на затылке. Отличный пример Twitter, работающего на Ruby on Rails. Они запустили его и заработали миллионы пользователей. Все было хорошо, пока… не стало. Одна заброшенная интернет-икона — знаменитый Кит-неудачник. Это появлялось каждый раз, когда серверная часть Twitter не могла обрабатывать столько одновременных пользователей, сколько было. Это случалось часто. Настолько часто, что пользователи чувствовали ностальгию, когда переставали видеть это или даже чувствовали себя неуместными.

Это один из минусов предположения, что «мы в основном думаем о том, что есть сейчас, а что будет потом, то позже». Ruby — медленный язык. Мучительно медленный язык; всегда был, всегда будет. Запустив серверную часть RoR, вы знаете, что в конечном итоге вам придется переписывать свое приложение с нуля.

При написании MVP у вас должна быть масштабируемость хотя бы в затылке. Существуют фреймворки полного стека с богатой экосистемой плагинов, которые гораздо более перспективны, чем Ruby’s Rails. Есть Node’s Nest или Fastify, Kotlin’s Ktor или даже Go’s Fiber.

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

Первоначально опубликовано на https://www.itmagination.com.