(Не)-большой тредик о том, какой подход, вероятнее всего, в скором времени приживется в большинстве компаний: от маленьких галер, до больших корпоратов.
Суть подхода заключается в том, что...
Он призван помирить два часто абсолютно зря враждующих друг меж другом лагеря — адептов ведра и овесеров и сплотить их перед единой задачей: написанием единого кода.
Один из его главных плюсов в том, что вкатиться в него проще простого и возможно на любом проекте,
где уже используется swift или kotlin.
Инструментарий и сами подходы к созданию языков дают возможность писать практически полностью интерполируемый друг меж другом код.
Изначально было презентовано тут:
Презентация туть: icloud.com/keynote/0heqgz…
К просмотру рекомендуется только сама презентация.
Еще в 2016 году, когда Swift и Kotlin были менее похожи, было проведено исследование по поводу того, возможно ли в одном проекте использовать Swift и Kotlin и насколько они будут похожи.
Во многих местах string similarity была выше 70%.
angelolloqui.com/blog/38-Swift-…
На сегодняшний день в бизнес-логике возможно совпадение до 83.33%.
Это совпадение возможно благодаря тому, что Swift намного ближе к Kotlin, чем Obj-C к Swift и Obj-C к Java.
Оба языка мультипарадигменные, на обоих код нативно компилится под обе платформы, есть optionals, extensions и кложуры в том виде, в котором мы их привыкли наблюдать.
![](https://pbs.twimg.com/media/EPXlM0eU0AILUq4.jpg)
Потрясающий сайт, который показывает внешнюю схожесть языков и доказывает, что котлинист может спокойно читать свифт код и наоборот.
nilhcem.com/swift-is-like-…
![](https://pbs.twimg.com/media/EPXnMQNXUAAA76g.jpg)
С приходом SwiftUI жизненный цикл стал еще более похож, чем был до этого.
На скринах до/после:
![](https://pbs.twimg.com/media/EPXn_9DWAAEoeCh.jpg)
![](https://pbs.twimg.com/media/EPXn_9DWAAIKXO7.jpg)
По своей сути языки почти ничем не различаются, за некоторыми исключениями и парой примеров синтаксического сахара
![](https://pbs.twimg.com/media/EPXo2ajX0AAg_dC.jpg)
Среди плюсов можно подчеркнуть то, что крайне просто вырастить внутри уже имеющейся команды людей, которые будут «скреплять» общий код и разносить в абстракции остальное.
Но, опять же, без фанатизма.
Хотя у нас есть #SwiftUI и #JetpackCompose, это не повод бросать
остальных пользователей.
Можно начать с постепенного «причесывания» приложения и слаженной работы между двумя командами, которой уже можно добиться многого.
В среднем на 1 команду требуется всего 3 человека, которые будут этим заниматься (в случае стартапов 1):
1) лид iOS/Android, отвечающий за архитектуру и предугадывание слабых мест данной концепции
2) один iOS Developer
3) один Android Developer
В случае команд, которые приняли решение делать так с самого начала, их почти всегда ждёт успех.
Слаженной командой можно добиться результата быстрее и качественнее, чем если та же команда будет заниматься кроссплатформенными решениями (xamarin/rn/flutter).
Я ни в коем случае не хейчу решения на RN/Xamarin/Flutter, они намного более экономически выгодны на этапе проверки теории и старте, но нужно понимать, что у любого подхода есть минусы.
К примеру, многие RN девелоперы даже не подозревают и искренне верят, что RN переиспользует системные компоненты, а не рисует на канвасе.
![](https://pbs.twimg.com/media/EPXtA3zXsAYg4xw.jpg)
1) Не требуется IDE не от Apple/Google, чтобы собрать, запустить и выложить код в стор.
Проекты того же гугла, фасебука и прочих постоянно закрываются, если они не достигают каких-то KPI, а дихотомия Apple/Google на рынке уже занята, поэтому...
... крайне важно, что ваша IDE просто не умрет через пару лет и вы сможете выложить в стор новую версию приложения.
К примеру, Apple/Google банит старые версии SDK и не пропускает их в стор (и правильно делает) и вы зависите не от них, а от сторонних вендоров.
Чем меньше зависимостей от сторонних вендоров в вашем приложении, тем выше шанс, что вы его сможете собрать и через 2, и через 3 года.
В случае с KN, RN, Flutter у вас хотя бы будет шанс на то, что коммьюнити сделает костыли для выкладки в стор, как это уже неоднократно было.
Native UI — возможность использования нативного UI это всегда хорошо, а еще лучше, когда он только такой.
Ведь намного лучше, когда ваш прямой «поставщик» сначала тестирует все на всех устройствах и только потом выкладывает в своё SDK — доделанное и оттестированное
Bridge -> Native
Очень частая ситуация, когда новое API еще не имплементировано, либо вам нужен доступ к API, которого просто нет в инструментарии вашего кросс-платформенного инструмента.
Я был крайне удивлён, когда не увидел его в Xamarin, кстати. У остальных +
Очень часто, кстати, в компаниях, когда питчат то, что нужно использовать RN/Flutter слышу про то, что есть возможность бриджинга, но в итоге люди вставляют костыли, а не изучают новое (Swift/Kotlin).
Ну и нативочка, всеми любимая нативочка.
Люди, которые делают компиляторы в Apple/Google просто так же свой хлеб едят, пытаясь вам максимально облегчить жизнь и сделать «хорошо».
Ну и я бы не стал себя и свой проект доверять в руки тех, кто свой флагманский продукт не может сделать юзабельным и нежрущим командой из 200 человек. Привет лицокниге!
Как обычно организуется процесс у нас, когда мы пишем именно так?
Вкратце сначала определяется целесообразность использования той или иной технологии.
Задается буквально пара вопросов себе и команде.
![](https://pbs.twimg.com/media/EPcg6QtW4AIJmID.jpg)
В случае, если мы попали на Swift + Kotlin, задаются следующие вопросы:
Был ли у кого-то опыт?
Есть ли желание у кого-то вести проект? (Достаточно ли квалификации? Можно ли ему доверить проект?)
Достаточно ли укомплектована команда?
Сколько у вас ресурсов?
Если решено, что «за» больше, чем «против» и верим в квалификацию и желание сотрудника развиваться — вперёд.
От этого выиграет и бизнес, и сотрудник:
+ опыт
+ облегчена дальнейшая поддержка
+ вы вырастите внутри команды нового лида/head of
А вот в случае старых давно запущенных проектов все не так просто.
Часто встречал такие ситуации, что «эффективные менеджеры» держали в заложниках ту или иную команду, не давая им ни дня на рефакторинг, предлагая делать это в нерабочее (!) время.
Причём аргументировали все верно, конечно:
* есть план продукта
* другая команда (ВНЕЗАПНО КОНКУРИРУЮЩАЯ — iOS/Android) уже давно все сделала (потому что у них нет техдолга)
* какой техдолг? У нас тут 30 фич на носу
Но здесь, опять же, ошибки по обе стороны конфликта.
Менеджер искренне не понимает ценность рефакторинга, а тимлид не может её объяснить.
В итоге мы получаем в проде контроллеры на 43000 строк, смесь разных архитектур во всем проекте и мертвые ссылки
Еще одна частая ошибка, что параллельная команда (iOS/Android) воспринимается как «противоборствующая».
Вы, блядь, 1 продукт делаете, вот и работайте вместе!
Но тут, опять-таки, в итоге приходим к одной и той же проблеме: мысль одной команды не может быть донесена до другой и наоборот.
В итоге у вас кровная вражда и борьба за KPI, когда могли друг друга поддержать, обе вырасти профессионально и эмоционально
На месте бизнеса, опять же, ничего не понятно.
В одной команде на 30% людей больше, но делает она в 2 раза медленнее. Почему?
В итоге имеем бесполезные встречи вида:
«КАК МЫ МОЖЕМ ВАМ ПОМОЧЬ?»
«Давайте сделаем 1 спринт рефакторинга»
«У НАС ПРОДУКТ KPI ВРЕМЯ ПЛАН»
И ситуация не будет двигаться ни в ту, ни в другую сторону, пока менеджеры с одной и тимлид с другой стороны не сядут и не достигнут консенсуса, который всех будет удовлетворять.
Рефакторинг чаще скорее нужен на 10-летних проектах, чем нет.
Идеальный вариант я видел лишь однажды: в отдельную команду выделили одних из самых старых членов команды и дали им около 3 месяцев на создание полноценной копии приложения с нуля.
В итоге плакала половина этажа, потому что они смогли. Кодбаза уменьшилась втрое, билдтайм уменьшился с 10 минут до «МЕНЬШЕ МИНУТА ААААА», а 9 женщин родили за месяц.
К сожалению, в текущих реалиях для большинства людей в корпоратах данный подход является чем-то из рода фантастики.
Но пройдёт пару лет (и нихуя не изменится) и наступит светлое будущее с SwiftUI и Compose.
Десятилетнее легаси является проблемой и золотого молотка (еее, бесконечный рефакторинг!), как и везде в индустрии, еще не придумано и, скорее всего, не будет.
Но, в конце-концов, что такое для корпората с ∞M$ 3 гребца и 3 месяца их времени на проверку теории?