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