Когда команды разработчиков нативных мобильных устройств изучают KMP, начать работу довольно просто. Сложности возникают при попытке масштабирования. Чтобы получить максимальную отдачу от KMP для вашей команды, а также для успеха KMP как платформы, нам нужно сделать масштабирование простым.
Обзор
Многие команды, занимающиеся разработкой мобильных устройств, испытывают трудности с масштабированием своих усилий по внедрению KMP. Причины этого легко понять, и они понятны любой команде, которая пыталась это сделать. Решения проблем масштабирования также не очень сложны, но они требуют подхода, специфичного для контекста нативной мобильной команды.
Основные темы, которые можно вынести из этого поста, следующие:
- Чтобы получить отдачу от KMP, ваша команда должна использовать его там, где она делает большую часть своей работы. Для нативных мобильных устройств это означает разработку фич.
- Модель публикации библиотеки не подходит для разработки фич.
- Объединение кода приложения и кода KMP в одном репозитории создает новые проблемы.
- Масштабирование KMP не должно быть сложным, но необходим план и подход, специфичный для команд, работающих с нативным кодом.
Контекст важен
KMP — это большая тема. Существует множество целевых платформ, и, особенно для нативной разработки, нет стандартного «слоя», на котором останавливается нативный код и начинается KMP.
Чтобы профессиональные рекомендации были полезными, они должны учитывать контекст. При обсуждении общего KMP для команд, работающих с нативными приложениями, речь идет о контексте:
- Вы создаете нативные мобильные приложения с командой нативных мобильных специалистов (Android и iOS разработчиков).
- «Команда» — это как минимум 2-3 разработчика, которые в основном придерживаются своей специализации.
- Ваша цель — сделать так, чтобы команда писала KMP в масштабе. Это означает больше, чем просто несколько модулей. Вы хотите, чтобы KMP составлял значительный объем вашего кода в будущем.
Масштабирование KMP означает, что KMP должен жить там, где происходит большая часть вашей работы. Очевидно, что это повлияет на всю команду. Масштабирование затруднено тем, что существующие подходы к KMP не очень хорошо применимы к нативным командам.
Что такое «масштабирование»
Масштабирование Kotlin Multiplatform означает:
- Использование KMP для значительной части вашего кода
- Эффективная разработка KMP
Масштабирование — самый важный этап внедрения, потому что именно при масштабировании появляется возможность получить реальную пользу от KMP.
До масштабирования ваша команда в основном экспериментирует с KMP, и повседневный рабочий процесс команды практически не затронут. Кода KMP будет немного, и вы, вероятно, будете писать его не очень эффективно.
KMP ценен только в том случае, если вы получаете какую-то выгоду от его использования. Количество написанного вами KMP и эффективность его написания определяют эту ценность.
Большинство команд внедряют KMP с помощью модели разработки библиотеки. При библиотечной модели развития код KMP хранится в отдельном репозитории. Версии публикуются из этого репо. Модель разработки библиотеки проста в настройке и не сильно влияет на ежедневный рабочий процесс команды. Мы также рекомендовали использовать библиотечную модель разработки, когда команды оценивают KMP.
Разработка библиотек обычно означает публикацию бинарных зависимостей, но мы больше не рекомендуем использовать этот подход.
Делитесь исходными текстами Kotlin вместо двоичных файлов
Мы больше не рекомендуем публиковать библиотеки с бинарными зависимостями. Вместо этого делитесь исходным кодом Kotlin.
Несмотря на то, что библиотечная разработка проста в реализации, вы не сможете использовать эту модель для масштабирования использования KMP. Для команд, работающих с нативным кодом, масштабирование означает разработку функций.
Разработка библиотек против Разработки фич
Давайте четко определим, что такое разработка библиотек и фич. Это интуитивно понятные понятия, но чтобы понять проблемы масштабирования KMP, мы должны убедиться, что говорим об одном и том же.
Разработка библиотек — это именно то, что и значит. Вы пишете библиотечный код. Важными характеристиками библиотечного кода являются:
- Модули логики, не связанные напрямую с вашей повседневной работой над приложением
- Версии публикуются линейно
- Обычно размещается в отдельном репозитории
То, какая именно логика находится в вашей библиотеке, не имеет значения. Важно то, что библиотечный код живет по своему собственному расписанию, отдельно от вашей повседневной разработки приложения. Например, сетевой код, различная логика (расчет налогов и т.д.) — все, что не связано с вашей непосредственной повседневной разработкой приложения.
Внешнее расписание и публикация версий означает, что вы не пишете код библиотеки одновременно с кодом приложения. Они слабо связаны между собой.
Разработка фич — это ваша повседневная разработка. Вы добавляете функцию в приложение. Вы пишете пользовательский интерфейс и логику, лежащую в основе этой функции, как единое целое, в одном и том же репозитории. Код для этой функции проверяется и сливается как единое целое.
Масштабирование означает разработку фич
При работе в режиме library dev код, как правило, меняется нечасто, и общий объем кода невелик. Это замечательно, когда вы тестируете KMP и изучаете его работу. Однако вы не получаете от KMP большой пользы. Просто не хватает общего кода, чтобы KMP оказал положительное общее влияние.
Масштабирование означает написание логики фич с помощью KMP. Почему? Все просто. Именно там находится большая часть вашей работы.
Почему масштабирование сложно?
Масштабировать KMP для нативных мобильных команд сложно. Есть несколько конкретных причин, но все они связаны с одной и той же основной проблемой.
Стандартная модель KMP не учитывает, как работают нативные мобильные команды. Она просто предполагает, что команды радикально изменят свою структуру и рабочий процесс.
Разработка библиотек — неправильная модель
Логика, которую вы пишете для поддержки вашего пользовательского интерфейса, должна редактироваться как единое целое с ним. Нажатие на кнопку должно что-то «делать». Хотя вы можете написать эту логику отдельно, это будет очень неприятно и неэффективно.
Библиотеки заставляют разделять логику. Конечно, вы можете настроить свою систему разработки так, чтобы можно было редактировать эту библиотеку локально вместе с кодом пользовательского интерфейса, но вы все равно будете вынуждены проталкивать код KMP через отдельный цикл рецензирования и публикации. Код приложения должен дождаться публикации кода библиотеки, прежде чем его можно будет отревьювить и смерджить. В небольших командах это будет неприятно, но функционально. Для больших команд это создаст серьезные проблемы с рабочим процессом.
Монорепо в помощь?
Очевидный ответ — перенести весь код, KMP и оба приложения, в единый репозиторий. Хотя единый репозиторий решит проблемы рабочего процесса, присущие библиотечной модели, модель монорепо создает свои собственные проблемы.
Все эти новые проблемы имеют одну и ту же первопричину. Любое изменение в коде KMP влияет на оба приложения. Это означает, что каждое изменение KMP требует нативной реализации и тестирования в обоих приложениях. Это вынуждает связать логику приложений и команды разработчиков, чего в противном случае не произошло бы. В посте «KMP для нативных мобильных команд — масштабирование: Почему это сложно?» подробно рассказывает о том, почему это проблема. В итоге вы получаете более медленный, сложный и потенциально неэффективный рабочий процесс разработки.
Попытки повысить эффективность разработки за счет внедрения неэффективного процесса непродуктивны.
Проблемы рабочего процесса
При любой конфигурации репозитория, библиотеки или монорепо, использование KMP сопряжено со значительным трением. Это создает стимул для инженеров, реализующих код функции, пропустить KMP и полностью реализовать функцию на родной платформе. Особенно в условиях приближающихся сроков отказ от KMP может показаться более эффективным (и, возможно, так оно и есть).
Слияние команд
Общаясь с разработчиками и менеджерами, заинтересованными в KMP, мы обнаружили, что желание «объединить команды» встречается довольно часто. Вместо разработчиков Android и iOS все будут изучать обе платформы и работать как одна команда.
Это более обширная тема, чем мы можем осветить здесь. Некоторые из моих мыслей вы найдете в статье «KMP для нативных мобильных команд — масштабирование: Почему это сложно?», и скоро будет более длинный пост.
Короче говоря, это рискованный план. Специалисты по нативной мобильной разработке говорят о “разрушении разрозненности” с тех пор, как началась разработка современных нативных мобильных приложений. У нас было около 15 лет, чтобы понять это, но и сегодня в большинстве команд специализированны.
За эти 15 лет было много людей, призывающих к «слиянию команд». Посты в блогах, выступления на конференциях, иногда реальные усилия. Каждые несколько лет аргументы о том, почему сейчас самое время, обновляются. Современные аргументы сосредоточены на схожести Kotlin и Swift, или Compose и SwiftUI, но я не нахожу их очень убедительными (об этом мы расскажем в другом посте). Что объединяет более современные аргументы с более старыми призывами к слиянию команд, так это логическое обоснование без наглядных результатов. Нет никаких доказательств того, что это сработает (но мы говорили с несколькими командами, которые пытались это сделать…).
Я не говорю, что вы не можете, просто это рискованно.
Я также хочу сказать, что, возможно, специализации существуют не просто так. Попытка обобщить команды может привести к негативным результатам.
Масштабирование не должно быть трудным
Основная тема серии постов «KMP для нативных мобильных команд» заключается в следующем:
- Профессиональные подходы к любому применению технологий нуждаются в соответствующем контексте и учете нюансов
- Нативные мобильные приложения с KMP, созданные командами, будут иметь совсем другие потребности по сравнению с декларативным UI, десктопными приложениями или любой ситуацией, когда есть только 1-2 разработчика.
- Лучше иметь план, который не требует радикального изменения того, как сейчас работают команды разработчиков нативных мобильных приложений.
KMP не заменяет платформу, на которой работает. Он ее принимает. Аналогичным образом и нативным мобильным командам не стоит пытаться радикально изменить то, как они работают. Эти командные паттерны сохраняются годами, и полагать, что KMP сделает их ненужными, конечно, рискованно.
Примите, а не заменяйте то, как работают родные мобильные команды.