Комментарии 2
Спасибо за статью!
1. было ли в случае с вашим проектом оправданно отказаться от кмп с учетом сказанного в выводах?
В случае, когда ваше приложение объемное, в нем вы хотите видеть множество сложных бизнес-задач, насыщенных логикой и вычислениями, если планируемое мобильное приложение будет лицом немаленькой компании с большим сроком поддержки и ведения новых функциональных механик, то разработка на нативной кодовой базе для каждой платформы станет более надежным проверенным временем решением.
если да, то почему не пошли в эту сторону? одно из преимуществ KMP - вы можете шарить только то, что вам нужно. то есть возможно совмещать нативный подход и KMP только в части проекта, поэтому переход был бы возможен, переписывание приложения не потребовалось бы.
в целом, не могу согласиться с этим пунктом, тк если в приложении много сложной логики, то ее шаринг (хотя бы частичный) даст больше выгоды, чем в мелком проекте: в разработке, исправлении багов, тестировании, поддержке.
2. по поводу команды:
пробовали ли подход когда ios-разработчики пишут shared код наряду с android-разработчиками?
по нашему опыту вкатиться ios-разработчикам в KMP не составляет проблем, а на рынке уже есть люди с этим опытом.
таким образом, не придется временно подключать android-разработчиков в проект и блокироваться разработкой общей части, разработчики становятся более универсальными, затраты на разработку сокращаются.
3. по поводу языка Kotlin:
на самом деле ios-разработчику не сложно вникнуть в kotlin, нужна только мотивация. современные языки достаточно похожи. при разработке проекта редко приходится затрагивать внутренности языка и сложные конструкции, на которых не хватит ios-разработчика. плюс можно в любое время проконсультироваться с android-разработчиком.
кстати, иосеры кайфуют от android studio )
4.
При этом, если в проекте используется подход DDD (domain-driven development), то разработка любой из платформ затруднительна, либо невозможна вовсе без бизнес-логики общего модуля.
эта же проблема будет и в нативной разработке, но если вы разрабатываете полностью нативно и android уже реализовал доменную логику, то ios это только предстоит сделать, а не переиспользовать уже готовое решение на KMP.
в задачах почти всегда есть информация о дизайне, поэтому можно договориться заранее о контракте между нативными частями и KMP. и разрабатывать логику и ui параллельно. но по нашему опыту эффективнее все-таки объединить.
5. вытекают ли проблемы приложения, о которых вы пишете, из технологии KMP: необходимость рефакторинга, трудности и ошибки у пользователей? это ведь присуще проекту на любой технологии)
Спасибо за комментарий!:) Постараемся ответить по порядку.
Да, такой вариант рассматривался. Но все же мы решили продолжать разрабатывать и поддерживать проект с использованием KMP, так как мы видим тенденцию развития данной технологии и уверены, что вскоре многие проблемы будут решены. В том числе путем перехода на новый UI Compose Multiplatform. Еще раз подчеркнем, что мы не утверждаем, что KMP — это плохая технология и ее нужно опасаться. Совсем наоборот. Мы говорим о том, к каким неочевидным трудностям управления проектом стоит быть готовым при использовании KMP, а также делаем вывод, что при росте масштаба проекта и сложности бизнес-логики растет и фатальность допущенных ошибок.
и 3. Согласны с вами по поводу современных языков программирования. На счет формирования команды автор полагает, что здесь решает, в том числе, владелец проекта и то финансирование, которое он готов вложить команду разработки. Универсальный разработчик - не редкость, но его экспертность дороже оплачивается. Такие специалисты конечно ценятся на проекте, но иногда нужно больше «неуниверсальных» рук и умов, чтобы уложиться в поставленные сроки)
Да, фиксировать контракты между доменной и нативными частями необходимо в любом случае. Но если приложение полностью нативное, то разработчики часто работают по конкретному флоу, реализуя все механизмы от самых низших слоев к высшим (если мы говорим Clean Architecture) и сам более гибко может менять контракт
Конечно нет, KMP не виновник проблем проекта) Все инструменты хороши, нужно уметь ими правильно пользоваться
Спасти проект: с какими трудностями мы столкнулись при разработке и поддержке мобильной кроссплатформы