Спасибо! Ну, если ребята не поленятся, сами ответят, но один разработчик из команды просит задачи только на Flutter. Другой разработчик перешел в соседний проект и начал писать тот на чистом Dart-е. Остальные пока не имели возможности выбирать, но тоже, насколько я знаю, готовы пробовать новое на чистом флаттере. Впрочем, есть соседняя команда, которая, по определенным причинам, выбрала стек flutter+kmm Так что ответ, скорее, второе
Да все нормально. Но был бы чистый Дарт, и статьи бы не было, наверное. По Дарту и так полно статей и информации. Тут же смысл статьи не "смотрите, как круто мы сделали, делайте только так, как мы", а "попробовали необычный стек, набили каких-то шишек и получили интересный опыт, решили об этом рассказать, вдруг кто задумывается об аналогичном стеке"
Если резюмировать - то разработчики отлично знали котлин и не знали дарт. Плюс хотели иметь резервный вариант по-быстрому написать UI на нативке, если вдруг flutter-UI будет медленным или неудобным.
Сейчас, по прошествии полугода, выбор пал бы на чистый флаттер, полагаю
Ну почему обязательно QR-кодом? И обычной банковской картой тоже через выносной терминал. А код может использоваться для скидок, програм лояльности и т.д. Само приложение синхронизируется с кассовым сервером, поэтому проблем с платежами нет. В любом случае, безопасность при использовании традиционного бумажного блокнотика и оплате наличными или карточкой ничуть не выше.
В случае использования приложения официанта ресторатор имеет гораздо больший централизованный контроль за происходящим, в этом, собственно, основной смысл
Ну формально да, оплата это мобильная касса, не совсем приложение официанта. Но у r_keeper эти два приложения объединены в одно: официант набивает заказы в приложение, оно передает все на сервер\стационарную кассу (на которой тоже можно сделать оплату), и это же приложение офицанта может принять оплату
А кто сказал, что в старом коде это все было? )) Начиная от тестов и кончая разделением. К сожалению, зачастую тот код, в котором разработчики нарыли ходов и хорошо ориентируются, не очень-то подходит для рефакторинга.
Продать идею было несложно. Был проведен аудит, менеджменту сказали - чтобы отрефакторить текущее приложение до состояния вменяемости нужен год, чтобы написать то же самое с нуля нужно полгода. Но отрефакторенное все равно будет хуже, ибо стек совсем уже плохо пахнет. Плюс разработчиков новых будет сложно найти, никому не хочется ковыряться в древнем стеке с задепрекейченным кодом. Плюс кроссплатформа даст большую выгоду в плане минимизации усилий. Менеджмент все равно боялся и говорил что-то похожее "стек в среднесрочной перспективе может вообще не подойти" . Для этого и сделали тестовые приложения на всех исследуемых технологиях и проверили, как оно.
А вот как оно оказалось в реальности, когда с нуля написали на выбранном стеке уже рабочее приложение и какие выводы сделали - про это во второй части статьи. Планируем выложить ее в течении пары недель
какие именно нативные функции необходимы для официанта в приложении, быстродействие ему не нужно т.к. бизнес логики кроме отправить запрос в rest api ему тоже не нужно, на мой взгляд. Даже nfc функционал зачем ему?
Ну оплата заказа карточками (в виде взаимодействия с драйверами терминалов), сканирование QR-кодов камерами, понимать состояние коннекта с интернетом и т.д.
С удовольствием бы, но в проектах используется проприетарный backend-API, руководство, к сожалению, не разрешило выкладывать код в открытый доступ Извините за поздний ответ, надеялся договориться
УважаемыйBringoffуже абсолютно верно ответил за меня на основные вопросы. Немного дополню его ответ:
зачем с нуля что то переписывать?
Если вы не сталкивались в своей жизни со старым дурнопахнущим кодом, который гораздо дешевле переписать с нуля, чем поддерживать, то я вам сильно завидую.
В целом, по грубой оценке, переписывание с нуля сэкономило 50% усилий (человеко-часов) и сильно повысило удовлетворенность разработчиков от работы, что тоже важно
я верно понимаю, что вы в приложении объединили все три слоя на которые разделили свое приложение?
Не очень понял вопрос. В приложении 3 классических слоя чистой архитектуры. Слой представления сделан на флаттер, остальные два - на КММ, все слои объединены в одном приложении
не понятен результат выбора технологии: вы окончательно перешли на выбранный технологический стек и если да то сколько времени вам на это потребовалось и сколько разработчиков в этом участвовали?
Да, в рамках этой части статьи описывался процесс выбора. В результате этого процесса мы перешли на выбранный стек и сделали рабочее приложение, о чем скоро будет рассказано во второй части
ну и самый важный вопрос, вы указывали что есть желание сократить ttm, какой он был средний и какой он стал после перехода на новый стек?
Не замеряли. Но за полгода был почти полностью повторен функционал старого приложения + внедрены фичи, которые висели в бэклоге пару лет. ttm совершенно явно значительно сократился
Извините, что повторяюсь, но еще раз приведу консёрны из статьи:
"Не было уверенности, что неопытный в этой технологии разработчик сможет качественно выстроить архитектуру и написать бизнес-логику. Мы также опасались, что кроссплатформа не позволит полностью реализовать все специфические особенности каждой платформы, вроде работы с push-уведомлениями или железом. Были сомнения и в достаточной производительности Flutter на слабых устройствах (такие нередко встречаются у корпоративных клиентов). "
Если резюмировать - то разработчики отлично знали котлин и не знали дарт. Плюс хотели иметь резервный вариант по-быстрому написать UI на нативке, если вдруг flutter-UI будет медленным или неудобным.
Сейчас, по прошествии полугода, выбор пал бы на чистый флаттер, полагаю
ну никто не мешает покрывать тестами обе части и делать изменения в контракте между флаттером и котлином максимально осторожно. Собственно, так у нас и происходит на практике
Но хотелось бы в идеале как-то автоматизировать проверку консистентности на этапе компиляции, тут целиком согласен
Именно писать 2 раза не приходится, есть же готовые конвертеры из JSON вроде https://javiercbk.github.io/json_to_dart/. То есть мы писали в kotlin-части сущности в виде data-классов, конвертили в JSON и потом его же в Dart.
Ну проблемы при общении между слоями всегда могут быть, разве общение с бэкендом через API и передача сущностей в обе стороны чем-то принципиально отличаются от общения flutter с kotlin? Там тоже могут быть проблемы с разными вариантами одного класса. На практике, в реальном проекте в этой части мы серьезных проблем не ловили Валидации на этапе компиляции нет, как прикрутить тут тесты не придумали
Вообще, во флаттере существует вполне удобный механизм для работы с платформой https://flutter.dev/docs/development/platform-integration/platform-channels. Можно и вызывать методы другого слоя напрямую, и подписываться на потоки, слушая изменения. Сущности через этот механизм platform-channels передаются через сериализацию\десериализацию в json.
во второй части статьи про это будет подробнее рассказано
А, собственно, в чем разница? KMM работает под WEB, даже недавно вышел драйвер под JS для БД SQLDelight. Flutter также в этом году в марте дошел до стадии релиза для Web. Схема та же, аналогична приведенной в статье.
Сложности могут быть, разве что, в том, что не все плагины под флаттер поддерживают веб. Но, конечно, надо пробовать этот вариант и тестить, там могут оказаться невидимые пока грабли
Спасибо!
Ну, если ребята не поленятся, сами ответят, но один разработчик из команды просит задачи только на Flutter. Другой разработчик перешел в соседний проект и начал писать тот на чистом Dart-е. Остальные пока не имели возможности выбирать, но тоже, насколько я знаю, готовы пробовать новое на чистом флаттере. Впрочем, есть соседняя команда, которая, по определенным причинам, выбрала стек flutter+kmm
Так что ответ, скорее, второе
Приветствую )
Не рассматривали, в нашем случае у этого варианта множество минусов и ни одного явного плюса:
Нужно кормить 3х условных программистов (android, ios и ++) вместо одного универсального андроид-флаттериста
нужно 2 раза писать UI на нативке для каждой платформы (а то и 3, для десктопа)
имхо, kotlin как язык, все-таки, гораздо современнее плюсов
Да все нормально. Но был бы чистый Дарт, и статьи бы не было, наверное. По Дарту и так полно статей и информации.
Тут же смысл статьи не "смотрите, как круто мы сделали, делайте только так, как мы", а "попробовали необычный стек, набили каких-то шишек и получили интересный опыт, решили об этом рассказать, вдруг кто задумывается об аналогичном стеке"
https://habr.com/ru/company/r_k/blog/578386/comments/#comment_23502166
даже не знаю, что еще сюда добавить
Ну почему обязательно QR-кодом? И обычной банковской картой тоже через выносной терминал. А код может использоваться для скидок, програм лояльности и т.д.
Само приложение синхронизируется с кассовым сервером, поэтому проблем с платежами нет. В любом случае, безопасность при использовании традиционного бумажного блокнотика и оплате наличными или карточкой ничуть не выше.
В случае использования приложения официанта ресторатор имеет гораздо больший централизованный контроль за происходящим, в этом, собственно, основной смысл
Ну формально да, оплата это мобильная касса, не совсем приложение официанта. Но у r_keeper эти два приложения объединены в одно: официант набивает заказы в приложение, оно передает все на сервер\стационарную кассу (на которой тоже можно сделать оплату), и это же приложение офицанта может принять оплату
А кто сказал, что в старом коде это все было? )) Начиная от тестов и кончая разделением.
К сожалению, зачастую тот код, в котором разработчики нарыли ходов и хорошо ориентируются, не очень-то подходит для рефакторинга.
Продать идею было несложно. Был проведен аудит, менеджменту сказали - чтобы отрефакторить текущее приложение до состояния вменяемости нужен год, чтобы написать то же самое с нуля нужно полгода. Но отрефакторенное все равно будет хуже, ибо стек совсем уже плохо пахнет. Плюс разработчиков новых будет сложно найти, никому не хочется ковыряться в древнем стеке с задепрекейченным кодом. Плюс кроссплатформа даст большую выгоду в плане минимизации усилий.
Менеджмент все равно боялся и говорил что-то похожее "стек в среднесрочной перспективе может вообще не подойти" . Для этого и сделали тестовые приложения на всех исследуемых технологиях и проверили, как оно.
А вот как оно оказалось в реальности, когда с нуля написали на выбранном стеке уже рабочее приложение и какие выводы сделали - про это во второй части статьи. Планируем выложить ее в течении пары недель
какие именно нативные функции необходимы для официанта в приложении, быстродействие ему не нужно т.к. бизнес логики кроме отправить запрос в rest api ему тоже не нужно, на мой взгляд. Даже nfc функционал зачем ему?
Ну оплата заказа карточками (в виде взаимодействия с драйверами терминалов), сканирование QR-кодов камерами, понимать состояние коннекта с интернетом и т.д.
С удовольствием бы, но в проектах используется проприетарный backend-API, руководство, к сожалению, не разрешило выкладывать код в открытый доступ
Извините за поздний ответ, надеялся договориться
Уважаемый Bringoff уже абсолютно верно ответил за меня на основные вопросы. Немного дополню его ответ:
зачем с нуля что то переписывать?
Если вы не сталкивались в своей жизни со старым дурнопахнущим кодом, который гораздо дешевле переписать с нуля, чем поддерживать, то я вам сильно завидую.
В целом, по грубой оценке, переписывание с нуля сэкономило 50% усилий (человеко-часов) и сильно повысило удовлетворенность разработчиков от работы, что тоже важно
я верно понимаю, что вы в приложении объединили все три слоя на которые разделили свое приложение?
Не очень понял вопрос. В приложении 3 классических слоя чистой архитектуры. Слой представления сделан на флаттер, остальные два - на КММ, все слои объединены в одном приложении
не понятен результат выбора технологии: вы окончательно перешли на выбранный технологический стек и если да то сколько времени вам на это потребовалось и сколько разработчиков в этом участвовали?
Да, в рамках этой части статьи описывался процесс выбора. В результате этого процесса мы перешли на выбранный стек и сделали рабочее приложение, о чем скоро будет рассказано во второй части
ну и самый важный вопрос, вы указывали что есть желание сократить ttm, какой он был средний и какой он стал после перехода на новый стек?
Не замеряли. Но за полгода был почти полностью повторен функционал старого приложения + внедрены фичи, которые висели в бэклоге пару лет. ttm совершенно явно значительно сократился
Спасибо, все верно, сам бы не ответил лучше
Извините, что повторяюсь, но еще раз приведу консёрны из статьи:
"Не было уверенности, что неопытный в этой технологии разработчик сможет качественно выстроить архитектуру и написать бизнес-логику. Мы также опасались, что кроссплатформа не позволит полностью реализовать все специфические особенности каждой платформы, вроде работы с push-уведомлениями или железом. Были сомнения и в достаточной производительности Flutter на слабых устройствах (такие нередко встречаются у корпоративных клиентов). "
Если резюмировать - то разработчики отлично знали котлин и не знали дарт. Плюс хотели иметь резервный вариант по-быстрому написать UI на нативке, если вдруг flutter-UI будет медленным или неудобным.
Сейчас, по прошествии полугода, выбор пал бы на чистый флаттер, полагаю
ну никто не мешает покрывать тестами обе части и делать изменения в контракте между флаттером и котлином максимально осторожно. Собственно, так у нас и происходит на практике
Но хотелось бы в идеале как-то автоматизировать проверку консистентности на этапе компиляции, тут целиком согласен
Именно писать 2 раза не приходится, есть же готовые конвертеры из JSON вроде https://javiercbk.github.io/json_to_dart/. То есть мы писали в kotlin-части сущности в виде data-классов, конвертили в JSON и потом его же в Dart.
Ну проблемы при общении между слоями всегда могут быть, разве общение с бэкендом через API и передача сущностей в обе стороны чем-то принципиально отличаются от общения flutter с kotlin? Там тоже могут быть проблемы с разными вариантами одного класса. На практике, в реальном проекте в этой части мы серьезных проблем не ловили
Валидации на этапе компиляции нет, как прикрутить тут тесты не придумали
Вообще, во флаттере существует вполне удобный механизм для работы с платформой https://flutter.dev/docs/development/platform-integration/platform-channels.
Можно и вызывать методы другого слоя напрямую, и подписываться на потоки, слушая изменения. Сущности через этот механизм platform-channels передаются через сериализацию\десериализацию в json.
во второй части статьи про это будет подробнее рассказано
А, собственно, в чем разница? KMM работает под WEB, даже недавно вышел драйвер под JS для БД SQLDelight. Flutter также в этом году в марте дошел до стадии релиза для Web. Схема та же, аналогична приведенной в статье.
Сложности могут быть, разве что, в том, что не все плагины под флаттер поддерживают веб. Но, конечно, надо пробовать этот вариант и тестить, там могут оказаться невидимые пока грабли
Да, порог освоения был выше. Плюс, менеджмент хотел, в перспективе, поддержку Linux