Позвольте мне с вами кое-чем поделиться. Мне нравится идея кросс-платформенной разработки. Возможность использовать один набор инструментов для всех моих задач — это мечта. Кто не хотел бы использовать только один инструмент, чтобы успешно выполнять свои задачи? Пиши один раз, запускай везде? Я хочу!
Мне также нравится идея утопического общества. Общество, где каждый уважает убеждения других, имеет значимые / логические / разумные аргументы и ставит перед собой задачу стать лучше, чем они были вчера. Тем не менее, реальный мир редко бывает, таким совершенным.
Хочу признаться, я уже давно хотел обсудить спор между нативной, кросс-платформенной и гибридной разработками приложений. Не из-за нехватки мотивации, а скорее из-за надежды или желания, что однажды объединенный набор инструментов появится, откроет двери и обеспечит наилучшую ценность для создания мобильных приложений. Я все еще жду этого дня, и эта статья должна помочь объяснить мою привязанность к нативному развитию.
Нативная, кросс-платформенная, гибридная? Шта?
Я мог бы подробно остановиться на различиях каждого типа ра��работки, но поскольку сравнения между ними можно делать очень долго, я постараюсь сделать эту часть короткой.
Нативная разработка
При нативной разработке мы используем специализированные инструменты для создания приложений для iOS или Android. То есть существует одна кодовая база для каждой платформы. В наборы инструментов обычно входят Swift / Objective-C + Xcode/AppCode для iOS и Kotlin/Java + Android Studio для Android.
Кросс-платформенная разработка
Мы используем платформу/инструмент, который переводит/компилирует/запускает ваш код как-будто нативные компоненты. Процесс отличается в зависимости от того, какие инструменты вы используете, но конечный результат заключается в том, что один и тот же код запускается и работает практически одинаково на платформах Android и iOS.
Некоторые примеры инструментов: Xamarin, React Native, Flutter
Гибридная разработка
При гибридной разработке мы используем платформу/инструмент, который запускает WebView, в котором затем размещается ваше приложение. По сути это означает, что ваше приложение является веб-сайтом, который запускается из собственного приложения. Платформа/инструмент обычно так же обеспечивает доступ к собственным функциям, таким как камера, через плагины.
Примеры инструментов: Cordova и Ionic
Первичные vs неотъемлемые характеристики
Чтобы правильно понять мой выбор, мне необходимо объяснить два разных типа характеристик инструмента.
Уже долгие годы ведутся споры, почему один инструмент лучше другого. В большинстве статей рассматриваются очевидные особенности инструмента, например размер кодовой базы, время разработки, количество платформ, под которые можно разработать приложения и так далее. Эти сравнения, я люблю называть «основными характеристиками» каждого набора инструментов. Основные характеристики инструмента являются наиболее прямыми, чтобы сравнивать их с другими инструментами, поскольку вы, обычно, можете эмпирически увидеть различия (т. е. Скорости разработки, время сборки и т.д.). Эти характеристики обычно беспокоят большинство людей, но они не раскрывают сути.
Чтобы полностью понять последствия выбора инструмента, необходимо учитывать «неотъемлемые характеристики». Эти характеристики, как правило, более тонкие и их влияние сложнее оценить, чем основные характеристики. К сожалению, понимание влияния этих характеристик обычно происходит только после того, как инструмент выбран и в него вложены большие средства. Этими характеристиками является полнота и понятность документации, наличие удобных инструментов и т.д.
Принятие правильного решения по инструменту разработки требует понимания его неотъемлимых характеристик.
Почему я выбираю нативную разработку
За годы разработки программного обеспечения у меня была возможность использовать несколько инструментов для разных проектов. Обычно выбор инструментов разработки делался за меня руководством или техническим инженером. Как только я перешел на фриланс, я решил определиться с технологическим стеком.
В конечном итоге мое окончательное решение сводилось к рассмотрению не только факторов инструментов, но и того, как неотъемлимые характеристики будут влиять на каждый мой проект в различных ситуациях в течение времени и вот мои умозаключения.
1. Постоянная популярность
Когда я впервые начал программировать в 2013 году, было много хайпа вокург Cordova и Appcelerator. Через несколько лет хайп перешел на Xamarin. Через несколько лет это уже был React Native. В настоящее время? Сейчас набирает популярность Flutter.
Я обнаружил, что популярность инструмента также представляет поддержку, которую он получает. Если инструмент принадлежит частной компании, то популярность приравнивается к продажам, что приводит к увеличению издержек на поддержку. Если инструмент с открытым исходным кодом, популярность зависит от того, сколько активных разработчиков улучшают кодовую базу. Популярность может приходить и уходить и влиять на всю экосистему развития вокруг этого инструмента.
Посмотрите на эту диаграмму Google Trends, которая показывает различные кросс-платформенные инструменты с течением времени.
График Google Trends примерно отображает результаты количества поисковых запросов для различных кросс-платформенных мобильных технологий.
Хотя эта диаграмма является приблизительной оценкой популярности (поскольку она представляет только результаты количества поисковых запросов), она действительно дает некоторое представление о том, что я испытывал как разработчик. Предприятия и частные лица, как правило, используют то, что является новым. Это не обязательно означает, что инструмент лучше или хуже (так как многие статьи будут спорить за/против, независимо от даты выпуска), но люди всегда переходят на что-то более новое.
Когда инструмент выпущен, он, как правило, раскручивается сообществом разработчиков и рассматривается как «будущее». Это может привести к тому, что старые инструменты будут иметь меньшую поддержку и медленно атрофируются с течением времени.
Противопоставлением этому является нативная разработка, которая гарантированно получит поддержку. Пока Apple поддерживает iOS, а Google поддерживает Android, нативная разработка всегда будет актуальна. Вот почему нативная разработка имеет самую большую экосистему разработчиков; это было только вокруг дольше и было последовательно в его популярности.
Еще одно соображение, которое нужно сделать, — это передача проекта. Вероятность того, что у следующего разработчика будет хоть какой-то опыт в области нативной разработки, достаточно высока. Даже если они не работают в основном с нативными инструментами, большинство разработчиков по крайней мере каким-то образом касались этих инструментов, что гораздо менее вероятно с кроссп-латформенными решениями.
2. Business Values/Vision
Я редко слышу, чтобы многие люди обсуждали ценность для бизнеса, сравнивая инструменты разработки. Я спрашивал об этом различных разработчиков и даже владельцев технического бизнеса, и самое часто, что я получил в ответ это был пустой взгляд. Важно понимать как соотносится ценность для бизнеса и конкретный инструмент и то, как он может эту ценность дать.
Например возьмем Xamarin. Еще в феврале 2016 года Microsoft купила Xamarin примерно за 400–500 миллионов долларов. В то время видение Microsoft было связано преимущественно с разработкой мобильных приложений. Они добились значительных успехов с этим инструментом и даже включили его в качестве надстройки «из коробки» для Visual Studio и Visual Studio для Mac. Перенесемся через несколько лет, и видение Microsoft перешло на искусственный интеллект.
На протяжении всей этой смены видений я работал над проектом с Xamarin. За это время я познакомился с платформой, с которой мне пришлось переходить из состояния стабильного набора инструментов в медленно деградирующий. Каждое обновление инструмента выглядело как попытка, хотя бы ничего не сломать. В лучшем случае все работало как надо. В худшем случае вы потратили часы или даже день или два, откатывая обновления и пытаясь вернуть свою среду в работоспособное состояние.
Эта медленная деградация не документирована на домашней странице Xamarin (что и понятно), но если вы будете искать информацию по форумам, вы можете почувствовать, что со временем что-то изменилось. Сообщения о вещах, которые раньше работали «из коробки», сейчас просто не работают или о том, как изменился опыт разработчика с этим инструментом. Все это напрямую влияет на стоимость разработки не только из-за сырых часов, но и из-за качества кода.
Притирка при переходе к новому инструменту приводит к увеличению накладных расходов и упущенной выгоде
Я признаю, что у нативной разработки тоже есть свои проблемы здесь. Например, Apple обычно пытается заставить разработчиков развиваться по определенному пути (например, используя Storybords или шаблон MVC). Инструментарий также не всегда идеален, поэтому я фактически использую AppCode для большей части своей разработки под iOS. Тем не менее, и Apple, и Google тратят огромное количество времени и денег, чтобы добиться того, чтобы разработчикам было комфортно разрабатывать нативные решения. Достаточно взглянуть на Android Jetpack, SwiftUI или даже перейти на Kotlin и Swift.
В конечном счете, у Google или Apple не лучшее видение в мире, но оно последовательное. Существует минимальная вероятность, что компании в одночасье откажутся от поддержки своих инструментов.
3. Сохранение времени
Ах да, экономия времени. Святой Грааль эффективности развития. Эта горячо обсуждаемая тема, касающаяся ЛЮБОГО инструмента разработки, может создать или разруш��ть бизнес. Эта тема находится на переднем крае любого проекта, поскольку напрямую влияет на стоимость. Но давайте сделаем шаг назад и зададим себе вопрос.
Что мы можем сделать, чтобы сэкономить время?
Я объясню. Как и в программном обеспечении в бизнесе, обычно существует несколько способов решения проблемы. Решение в основном исходит из ситуации конкретного человека или бизнеса. Это означает, что подход «одно решение подходит всем» опасен; это также очень близко подходит к менталитету «мы всегда так делали». К сожалению, когда речь заходит о мобильной разработке, общий подход к экономии времени заключается в выборе кросс-платформенного инструмента. Но так ли это хорошо? Можем ли мы, скажем, придумать другой метод решения проблемы? В бизнесе есть поговорка «Люди превыше процессов, превыше инструментов».
Люди превыше процессов, превыше инструментов
Это именно то, что следует учитывать при принятии решения. Как влияет время разработки между выбором инструмента и созданием процессов/процедур или даже созданием другого подхода к разработке?
Инструмент сможет решить плохой менталитет при разработке?
Позволяет ли инструмент упорядочить процесс разработки?
Может ли слегка измененный процесс или менталитет привести к лучшим результатам, экономящим время?
Можем ли мы использовать инфраструктуру для решения наших задач?
Все это правильные вопросы, которые также показывают сложность решения. Все не так просто, как выбор очередного кросс-платформенного фреймворка вместо нативной разработки. Что подходит для вас или вашего бизнеса? Только вы можете сделать этот выбор.
Поскольку нативная разработка по-умолчанию будет производить продукт более высокого качества и поддерживаться практически до бесконечности, я выберу этот набор инструментов. Мои личные ценности определяют этот выбор (стремиться к совершенству). Собственное развитие действительно занимает больше времени (насколько больше сильно варьируется). Есть ли способ сэкономить время? Должен ли я вообще экономить время? Должен ли я просто искать проекты, где бюджет не является проблемой?
Одним из способов решения проблемы экономии времени является создание кода, который можно переиспользовать. Создавайте качественный и переисползуемый код, который можно быстро интегрировать и развертывать в нескольких проектах. Так как я выбрал набор инструментов с учетом долговечности, я могу быть уверен, что мой переиспользуемый код будет пригоден в течение некоторого времени.
4. Прочие умозаключения
В конечном счете, я сделал много других умозаключения, прежде чем выбрать нативную разработку. Многие из которых я сделал за всю свою карьеру, пробуя различные инструменты, процессы и подходы. Описание всего этого сделало бы эту статью невероятно объемной. Поэтому для краткости я приведу тезисы некоторых из них.
Вещи, которые я рассмотрел перед выбором нативной разработки:
1. Время на Onboarding разработчика
2. Вспомогательная инфраструктура
3. CI/CD Pipelines
4. Стоимость поддержки legacy проектов
5. Слои абстракции = больше возможностей для ошибок
6. Наличие разработчиков (количество разработчиков, использующих указанный инструмент)
7. Бизнес-иерархия (у Airbnb есть отличная серия блогов, которая затрагивает эту тему)
8. Зависимость платформы от плагинов
9. Счастье разработчика при использовании инструмента
10. Затраты на проектирование: необходимость проектирования таким образом, чтобы поддерживать обе платформы
11. Нестандартная структура проекта
12. Ресурсы знаний — количество областей знаний, необходимых (например, Xamarin требует: + платформа Xamarin Api, C #, специфическая функциональность Android, специфическая функциональность iOS и знание особенностей каждой платформы и того, как они взаимодействуют через Xamarin.)
13. Лицензирование + стоимость
14. Ландшафт мобильных операционных систем. Например: как долго будет только 2 основных платформы?
Выводы
В течение последних 2 лет использовал нативную мобильную разработку в качестве основного набора инструментов. Одна из многих причин, по которым я доволен своим решением, состоит в том, что я нашел время, чтобы рассмотреть как можно больше тонкостей для каждого инструмента. Я знаю плюсы и минусы, и это дает мне преимущества.
Я надеюсь, что эта статья поможет вам задать правильные вопросы при выборе инструмента. Не принимайте маркетинг за чистую монету, и ПОЖАЛУЙСТА, не следуйте за хайпом. Копайся, пачкайся и думай критически.
