Как мы обновляли мобильное приложение для официантов: выбор стека и тест трех версий. Кто победил?

Признаюсь честно, последние 3 года, где я работал - начинал именно с разгребания легаси и дурно пахнущий кода, внедрение линтеров, код ревью, тестирования, типизации, ci/cd и отсутствия документации.
В связи с этим, всегда интересен опыт компании, которая перешла с одного стека на другой.
Потому и спрашиваю, ведь переход на новый стек - это всегда вопрос компромиссов и дополнительных ресурсов. Когда говорят что "мы хотим улучшить ttm" то всегда встает вопрос "улучшили?" и метрика в виде "явно значительно сократился" немного расплывчата и не говорит вообще ни о чем, ведь мы должны продать бизнесу идею перехода на новый стек, а не "просто потому что". Из этого и спрашиваю, что переход на другой стек (который в себя вбирает обучение своих сотрудников языку и фреймворку, построению верного релизного цикла и разработки, переделка с нуля всех компонентов вью, переделка с нуля всей бизнес логики, обмазывание всего тестами, возможно описание новых интеграционных и e2e тестов, а самое главное, что стек в среднесрочной перспективе может вообще не подойти) действительно ли дороже трансформации текущего кода в котором уже есть тесты и который разрабы знают как свои 5 пальцев (рефакторинг и разделение вью и бизнес логики, что бы подготовить базу к возможной смене одного из слоев архитектуры на любую другую технологию)?
Особенно интересено, для меня, в связи с частичным уходом компании Wrike от Dart и перехода на Typescript их вью части. И да, я понимаю, что у них веб приложение, а у вас нативка. От того более интересно, с какими проблемами вы встретились как со стороны языка, так и со стороны фреймворка

Как мы обновляли мобильное приложение для официантов: выбор стека и тест трех версий. Кто победил?

На мой взгляд, тут больше вопрос не "на чем", а "зачем":
- зачем с нуля что то переписывать?
- зачем был выбран flatter (на Dart) вместо React Native (на javascript) если команда не знала ни тот ни другой язык?
- зачем вам вообще было нужно нативное приложение (какие преимущества вы ожидали в отличии от веб версии)?
- если разработка хотела на kotlin и знала его, то почему не был выбран https://github.com/JetBrains/kotlin-wrappers/tree/master/kotlin-react?
- зачем вам в вашем приложении в котором выводится картинка и информация, нужно быстродействие нативного приложения?
- я верно понимаю, что вы в приложении объединили все три слоя на которые разделили свое приложение?
- не понятен результат выбора технологии: вы окончательно перешли на выбранный технологический стек и если да то сколько времени вам на это потребовалось и сколько разработчиков в этом участвовали?
- ну и самый важный вопрос, вы указывали что есть желание сократить ttm, какой он был средний и какой он стал после перехода на новый стек?

Прекратите изучать фреймворк, станьте JavaScript-разработчиком

Для тех кто обманом или по удаче смог попасть на не соответвующее ему место - есть испытательный срок в 3 месяца в любой конторе. Ведь это деньги компании, которые она будет платить ожидая некоторый уровень качества решения задачи. Которые, возможно, надо будет править привлекая большее кол-во времени более скилловых и высокооплачиваемых разрабов, кто мог бы запилить эту таску сам за пару часов, а не объяснять на код ревью почему это решение его не устраивает.

Если кандидат за собесы выучил ответы на все вопросы - это тоже хорошо, как минимум он узнал что то новое. Лично я всегда рассматриваю собес, как проверку знаний и возможность научиться чему то новому.

На собесах вообще что то сложно спрашивать помимо общих принципов разработки, платформы, каких то прошлых решений и знаний особенностей es6. Всегда закладывается то, что кандидат может чего то не знать, но испытательный покажет. Не заставлять же кандидата решать таску твоего беклога.

Как раз за счёт разношертности экосистемы реакт и возникают вопросы к знаниям js.

Прекратите изучать фреймворк, станьте JavaScript-разработчиком

В могли бы вы пояснить, что в вашем понимании "глубокие знания js"?

Как попадает товар в магазины «Леруа Мерлен» с точки зрения математики заказа

я не знаю, так это или нет. Возможно следует обратиться в компетентные органы. Но на мой взгляд, хабр — это тех ресурс, а статья имеет определенную тематическую направленность. Для того, чтобы пожаловаться, что вас каким-либо образом обманули, есть другие ресурсы и каналы.
Смысл сюда с этим идти, если проблема, с которой вы столкнулись, не может быть решена автором поста?

Как попадает товар в магазины «Леруа Мерлен» с точки зрения математики заказа

исторически так сложилось, при попытке смены стека примерно 3 года назад. в меньшей степени битрикс, я бы сказал, что он доживает свое.

Как попадает товар в магазины «Леруа Мерлен» с точки зрения математики заказа

Вы действительно уверены, что данный вопрос уместен в рамках текущего топика, а не должен быть адресован службе поддержки ЛМ?
А вообще, от ошибки человека не застрахована ни одна система. Тут явно она.

Как попадает товар в магазины «Леруа Мерлен» с точки зрения математики заказа

не три, а четыре. А если быть вообще честным, то пять) Но, как говорится, «должен остаться только один»

Опыт интеграции веб-компонентов на сайт Леруа Мерлен

Леруа Мерлен Россия, подпадает под юрисдикцию законов Российской Федерации. В статье, которую ты скинул, прописаны обязательства для гос органов или коммерческих структур которые получают субсидии и гранты из федерального бюджета или любые другие деньги от государства.
Я не говорю, что доступность нам не нужна или мы не собираемся ее обеспечивать. Я описал лишь негативный момент текущей реализации.

Опыт интеграции веб-компонентов на сайт Леруа Мерлен

Поиск — это бековая система. Фронт получает только саджесты по АПИ. Про поиск знаю, что там грядут большие изменения.

Знакомство с lit-element и веб-компонентами на его основе

День добрый.
При переработке текущего сайта мы изначально взяли модель ленивой подгрузки логики и стилей для компонентов, на основе вью браузера и динамических импортов, тем самым заложив на будующее основу при которой не придется сильно беспокоиться о размере бандла и кол-ве лишнего кода (по крайней мере, надеемся на это)а так же, возможно поможет при построении микрофронтендов.
В динамическую подгрузку попадают элементы которые предположительно могут быть переиспользованны на сайте независимо от страницы и контекста, компоненты от которых они зависят однозначно импортируются без динамики в ленивые компоненты, далее webpack сам разбивает код на чанки в зависимости от зависимостей для каждго компонента.
При таком подходе, мне на пилотных проектах удавалось достичь общего размера js не более 60кб (учитывая, что там еще и css в этих js) и 1/3 из этого загружалась только тогда, когда пользователь долистывал до футера. А используя http2 протокол мы можем дробить наши компонентики как угодно мелко.
Опять же, нам понадобилась такая система при SSR на java, где «пользователю» предоставлен режим автора и он может на страницу накидать все что угодно и это должно как то работать между собой и не ломаться

Знакомство с lit-element и веб-компонентами на его основе

Сорь, но:

1. Из текста «Я не являюсь экспертом в данной технологии», «это дико, но имеет место быть», «Мое мнение». Я не считаю нужным вешать там огромный баннер «не делайте так!», там где высказываю личное мнение. По поводу бесполезности оптимизации, если есть желание, я предлагаю Вам доказать несостоятельность этого подхода. Я высказал свое мнение и в комментах подтверждаю «По идее, это должно повлиять на конечную скорость отрисовки. А по факту, в большинстве случаев — это «экономия на спичках».»
2. На этом, считаю, что данная ветка в дальнейшем не актуальна. Если есть желание в дальнейшем подискутировать на эту тему, то велком в личку

Знакомство с lit-element и веб-компонентами на его основе

немного фуфуфу, но самый простой вариант например такой codesandbox.io/s/my55o3zywx
Для поддержки абсолютно не рабочий вариант и нужно еще сменить parcel на что то более управляемое, что бы дробил на чанки, но как пример сойдет

Знакомство с lit-element и веб-компонентами на его основе

еще не пробовал. ща попробую сделать такую сборку и посмотреть что получится

Знакомство с lit-element и веб-компонентами на его основе

дак я и не призываю, а высказываю личное мнение и указываю, что это лишь «идея». Так же говорю что это «экономия на спичках».

Знакомство с lit-element и веб-компонентами на его основе

идея в том, что бы отдать браузеру как можно меньше информации для расчетов, т.к. вне зависимости от того будет ли использоваться стиль или нет, браузер все равно учтет его при отрисовке. По идее, это должно повлиять на конечную скорость отрисовки. А по факту, в большинстве случаев — это «экономия на спичках».
По поводу бандла. использовать динамический импорт и нет проблем с объемом

Знакомство с lit-element и веб-компонентами на его основе

спасибо. еще не пользовался этим методом. учту в дальнейшей работе

Знакомство с lit-element и веб-компонентами на его основе

нет не буду. Это лишь мое мнение основанное на наблюдениях и анализе других сайтов («здесь и сейчас»). Если взять среднестатистического пользователя с мобильным устройством, для которых я делал сайты, то о ресайзе окна там никто не задумывается, это очень редкий кейс. А по поводу смены ориентации, то на мобильном устройстве горизонталка — это как смотреть в амбразуру, и некоторые сайты просят пользователя вернуться в вертикальное положение устройства. При этом, мне никто не мешает резко отказаться от медизапросов и лить все воедино.

static get styles() {
  const mobileStyle = css`p { color: red; }`;
  const desktopStyle = css`p { color: green; }`;

  return [
    mobileStyle,
    desktopStyle
  ];
}

не забыв добавить медиазапросы к стилям

Знакомство с lit-element и веб-компонентами на его основе

там скорее всего будет разрешение как для таблетки)) Но будет интересно посмотреть когда они появятся в продаже. А пока я все так же считаю, что это не рабочий кейс

Custom elements в бою

Спасибо за статью. Для adoptedCallback() я так же не могу придумать живой пример применения