Comments 7
Будущее за Kotlin Multiplatform, если он сможет победить React Native и Flutter. Так что мы внимательно следим за JetBrains. :^) Им уже получилось один раз расправиться с Eclipse и NetBeans-ом, а во второй раз помочь сделать Android Studio и пнуть джаву на Android-e. Так что это безусловно опасная фирма.
Суммарно получилось 2072 часа рабочего времени Android-разработчиков и 843 часа рабочего времени iOS-разработчиков. Получается, что затраты на iOS часть составили всего 40% от затрат на общую и Android части!
Не понятно как вы сделали этот вывод. Предположим если без KMM у вас было 1000 на Android и 1000 часов на iOS, потом появился KMP и к этому коду добавился еще 1000 часов. То все равно выглядело бы так что на iOS ушло всего 50% времени разработки!
> По количеству строк кода тоже заметна польза. Android, common и iOS части приложения получились примерно равными по количеству строк. Получается из каждого приложения, Android и iOS, мы вынесли в общий модуль примерно половину их кода. А это уменьшение затрат на разработку на 33%!
Тот же аргумент. Процент iOS кода уменьшился только благодаря тому что Android кода стало больше.
Если я был должен Васе 100 рублей, потом занял у Пети 900 рублей это не значит что мой долг Васе сократился в 10 раз (со 100% до 10%).
Плюс подмечу, что по моему опыту, в проект на 20-30 тыс. строчек кода без учёта кода библиотек и т.д. можно упихнуть практически любой функционал. Так что если для поддержки основного кода требуется наличие такого количество iOS кода, то выглядит всё отнюдь не радужно.
Процент iOS кода уменьшился только благодаря тому что Android кода стало больше.
Да, отчасти это так, я об этом писал в выводе:
Да, сейчас видно, что возможности KMP огромны — можно обобщать большую часть кода между платформами, экономить время и ресурсы. Но всё-таки, часов Android-разработчиков уходит больше, чем при нативной разработке.
Думаю, нужно было это прямо в том пункте и написать, чтобы не вводить в заблуждение, спасибо за замечание.
Но зависимость не 1:1, то есть уменьшение затрат со стороны iOS команды не спровоцировало увеличения затрат Android команды на аналогичный объем. Поэтому, даже с учетом бо́льших затрат со стороны Android-команды экономия ресурсов все же есть, просто она меньше 40%.
Насчет 20-30 тыс. строк кода как будто бы довольно странное утверждение, учитывая, что проекты бывают совершенно разные.
Да в целом я это и хотел сказать, вы все правильно поняли.
Насчет 20-30 тыс. строк кода как будто бы довольно странное утверждение, учитывая, что проекты бывают совершенно разные.
Да приложения бывают разные, но рефакторинг и повторное использования кода позволяют удерживать кодовую базу в разумных приделах. Что-то вроде эффекта сжатия - когда архивируется небольшой кусок текста, например, LZW алгоритмом, то эффективность сжатия низкая, а когда кусок текста большой - эффективность растёт настолько что конечный размер архива практически перестаёт зависеть от объёма текста.
Вот даже картинка есть (LZW compression results-text length dependence):
Что-то подобное происходит и с кодовой базой за счёт повторного использования.
Конечно речь не про супераппы где могут быть объединены приложения совершенно разной природы, а когда функционал наращивается в конкретной доменной области.
Удивительно, из мультиплатформы, пытаются сделать кроссплатформу, и самое забавное, ориентируются именно на кроссплатформу! Молодцы, мало того что откинулись на два десятка лет назад, когда ровно тоже делали, только без слов "котлин мультиплатформ", так еще и на те же грабли наступают, в следствии чего, и многие айти гиганты, начали развивать кроссплатформу, но нет, в джетбреинс классика, сделать херню и продвигать ее под видом современных технологий. Очень современно, писать платформенный код под две платформы, и шаред с констрированной стд либой, в которой ни работать с валютой невозможно, ни с временем (я даже не упоминаю огрызок kotlinx.time), с японским временем нормально не поработаешь, оффсет от зоны парсер отличить не может, валюты, проценты, большие числа, все что встречается в любом крупном приложении, тут будет задачей изобрести то, что существует уже десяток лет в JDK, в дотнете. Весело дурят котлинистов, в основном тех, кто относится к категории вкатуны и зумеры.
Я думаю за флаттером уже не угнаться.
Kotlin Multiplatform в мобильной разработке. Рецепты общего кода для Android и iOS