😮 Entity Framework или Dapper?

Года два назад задался вопросом. Как решить, что использоваться для взаимодействия с базкой в своем проекте ORM или миниORM?
 
Вот в Додо исконно принято использовать даппер. Хотя это и не обязательно, и в ряде проектов, к примеру в Базе знаний используется EF. Но почему-то если проект у нас критический, то там используется именно даппер.
 
В своих пет-проектах я год пользовался EF, ну а в работе понятное дело юзал даппер. И вот к каким выводам я пришел.
 
Entity Framework:
🟣Практически в любом случае проще и лучше использовать EF.
 
🟣Для старта любого проекта, на котором большая нагрузка либо не предвидится, либо пока неясно, будет ли она, лучше использовать EF.
 
Dapper:
🟠Если у вас проект, который использует какие-то особенности базы для работы, то есть у вас сложная иерархия таблиц, с индексами, вьюхами, прости Господи хранимками, и по сути часть вашей бизнес-логики лежит в базе (что я не приветствую), то лучше юзать даппер.
 
🟠Если у вас меганагруженный проект с огромным количеством (несколько сотен в секунду) чтений из базы и вы по какой-то причине не можете использовать кэширование для оптимизации, то тоже можно использовать даппер.
 
🟠Если у вас бОльшая часть команды ОЧЕНЬ глубоко знает работу какой-то конкретной базы данных и прям использует по максимуму все её фичи, то тоже даппер.
 
🅰️ Короче, я для себя пока аккуратно сделал вывод, что по дефолту буду юзать EF, а над использованием Dapper скорее буду думать, надо ли.
 
Понимаю, что многие делают выбор в сторону даппера из-за скорости. Но как часто действительно важна эта скорость? Ник Чапсас снял видос про то, что EF хорошо ускорился в основных сценариях использования и в принципе не сильно отстает от даппера. То есть скорее всего бутылочным горлышком у вас окажется не библиотечка, а кривой запрос/отсутствие индекса и так далее.

Такие пироги! Если что, это мнение не конечное, и я бы с удовольстием послушал ваш опыт. Было бы пиздатенько, если бы в коментах кто-то рассказл кейс, как EF что-то сломал в проекте, а Dapper даппер или что-то такое это починило. Ну или может еще накидал разных поинтов.

🗡 Топовая Polytopia!

Я вообще не играю в мобильные игры. Когда-то давно пробовал гонять во всякие клэш рояли, шутаны и прочую ерунду, но все не заходило. А вот Политопия жесть как зашла. Да так, что я не могу вам её не порекомендовать!
 
Самое просто описание Политопии – это мини-цива (цива – она же цивилизация Сида Мэйера) с партиями на 15 минут и небольшим деревом технологий. Так что, если вам нравилась когда-либо хоть какая-то Цивилизаиця, то эта игруха точно вам зайдет.
 
По ощущениям немного напоминает шахматы, только без задроченных комбинаций эндшпилей, этюдов, миттеншпилей и прочей вот этой душной поебени (когда-то играл в шахматы сам, но потом у меня проявилась аллергия на снобизм от любителей этой игры).
 
В игрухе отличный баланс и есть много классных механик, когда приходится придумывать и считать ходы, чтобы выкрутиться из изначально проигрышного положения. К примеру:

🥇 По ресурсам враг опережает тебя в два раза. То есть может строить в два раза больше армий, и в два раза быстрее может открывать технологии. Казалось бы – победа за ним.
🏔 Но у тебя есть рядом горы, в которых урон твоим юнитам снижается, а значит, ты можешь посчитать, что по армии у вас получается паритет.
🎄 А значит тебе нужно только сфокусироваться на нужной ветку технологий, на такой, которая позволит тебе добывать или экономить ресурсы лучше противника, пока он будет качать все подряд, тратя ресурсы на расфокус.

И вариативность довольно высокая. А еще с этой игрой очень удобно ждать в очередях – время проходит незаметно. Жалко, что это не поможет моим застрявшим сообщениям в кафке.

В общем, горячо рекомендую. И наивно полагаю, что эта игра помогает развивать интеллект 😭

🙏 or 🤬 Хвалить или ругать?

После того как у нас отключили слак, мы переехали на другой мессенжер, название которого почему-то никто не употребляет публично. Я хз почему, может НДА и все такое. Короче, назову его тут "Яблочко".

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

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

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

И вот каждый раз, заходя в этот канал, я читаю недовольные отзывы наших ребят и девчат, что вот мол там не так, тут тупит, там не едет и так далее. Менеджеры Яблочка всегда отвечают вежливо – из чего я заключаю, что на том конце сидят не мудаки.

При этом, если у Яблочка появляется какая-то фича, которая устраняет боль, то не то чтобы люди совсем не говорят там массовое спасибо, но до сообщений с благодарностями долистать у меня не получается.

И вот ставлю я себя на место разработчиков Яблочка: Что я бы думал, если бы видел такие отзывы? Стал бы я работать лучше? Пропитался бы к людям понимаем и эмпатией и, как следствие, делал бы для них фичи быстрее, качественнее и с любовью? Хуй там! Однозначно – нет.

Такой я человек – если меня похвалить, то могу неделю работать с полной самоотдачей, без перерывов на обед и даже на выходные. Потому что чувствую, что нужен людям и "как же они там без меня". А если меня поругать, то это вызовет обратный эффект.

🅰️ Не подумайте. Тут я не защищаю разработчиков и менеджеров Яблочка, и не выступаю за оголтелую похвалу по делу и без, но кажется, что если сочетать похвалу и честную обратную связь, это как минимум не навредит, а как максимум ускорит решение твоих проблем. Это ж экономически выгодно – затраты на "спасибо" нулевые, а профит возможен с некоторой долей вероятности. Так почему бы не воспользоваться? И это не только про Яблочко, так со всеми.

Или все же у похвалы есть какие-то экономичские издержки?

🪙 Сходил на вебинар про Developer Experience

Если и есть на свете чувак из айтишки, на которого я хочу быть похожим (по скиллам и профессиональным навыкам, внешне мы и так похожи), то это Федор Борщев. Чел топит за чистый и понятный код, руководит своей компанией по заказной разработке (при этом все еще пишет код!) и вообще всячески продвигает принципы no-bullshit и всего вот этого.
 
Не смог удержаться и сходил на его вебинар по Developer Experience. Он же DevEx. Если кто не знает, что это такое – то, коротко, это про то как сделать работу программиста охуенно удобной.

И это не столько про удобные кресла в офисе, кальяны и печеньки на кухне, сколько про сам процесс написания кода.

В общем как сделать процесс написания кода максимально пиздатеньким. Основные тезисы, которые я для себя отметил:
 
Любой опыт работ с кодом состоит из пяти этапов:
🟠получение доступов,
🟠настройка проекта у себя и работа с окружением,
🟠работа с задачами (таск-трекер и общение вокруг задач),
🟠написание кода,
🟠починка прода в случае поломок
 
По всем пунктам кроме третьего в общем-то ничего необычного я не услышал:
Получение доступов – настраиваем SSO. Настройка проекта – сделайте так, чтобы запускался в контейнере, чтоб не тянуть лишние зависимости + настройте dependabot. Написание кода – покрывайте все тестами и не забывайте про линтеры + чистый код. Починка прода – настройте мониторинг с базовыми метриками.

⭐️ А вот по поводу общения вокруг таско мне было, что узнать нового. Потому что это касается личной боли.

В Додо проходит дохуя встреч. Это какая-то прям напасть. Когда я только пришел их тоже было много, но они как будто были по делу. Сейчас я порой прихожу на PBR, где обсуждается какая-то таска для iOS и Android и я никакого инпута принести не могу. Но ходить просят – вдруг че полезного скажу.

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

🅰️ Так вот топ-совет от Федора Борщева (в моем скромном рейтинге) по поводу синков – нахуй синки! Нужна ровно одна встреча – "встреча 50%". Перед началом задачи у разработчика нужно спросить: "к какому дню сможешь сделать?" Он ставит срок. По истечении половины спрашиваешь: "Получилось ли сделать половину?" Если нет, то корректируешь срок.

Все остальные кейсы регулируешь асинхронной коммуникацией. Ну то есть – сделал раньше, напиши, и бери следующую.

Короче, теперь буду топить за то чтобы попробовать такой подход.🌚

🅰️ Еще мне понравилась идея – прикреплять к задаче бизнес-метрику, на которую эта задача влияет. Чтобы сразу было видно, что конкретно ты принес.

В прошлой команде очень очень хотел такое сделать. Помешало только то, что метрика была очень иннерционная и увидеть импакт от задачи можно было только через несколько месяцев. Но первый шаг мы сделали – начали метрику собирать и регулярно на неё смотреть и это уже было лучше, чем просто делать таски вслепую.

В общем, мне вебинарчик понравился. Несмотря на то, что я не узнал много нового, просто приятно было прийти туда, где твои взгляды разделяют.

🙅 Не называть классы …Service

У Дерека Комартина во многих видосах явно проявляется нелюбовь к такому окончанию. Когда он видит в репозитории что-то там Service то недовольно фыркает и говорит "It doesn't say anything about what it's doing!” 😡
 
И вот знаете что, я с ним согласен. Более того, для меня это превратилось в небольшое правило, которое помогает писать код лучше.
 
Каждый раз, когда я хочу назвать что-то Service, я задаюсь теперь вопросом, а что эта штука будет делать на самом деле? И всегда это приводит к тому, что либо я лучше понимаю, что хочу написать, и какие тесты нужно под это придумать, либо к тому, что я понимаю, что то что я хочу нужно разделить на более специфичные классы.
 
❌ К примеру IQuestService. Что он вообще делает? Ну что-то с квестами. Либо позволяет их создавать, либо редактировать, либо награду за него выписывает. Короче, вы поняли, ни зги не видно.

✅ А можно назвать так: IQuestStartRequierementsChecker – сразу понятно, что эта штука проверяет, можем ли мы начать квест или нет.
 
Как и со всеми остальными правилами написания понятного кода, всегда есть исключения и компромиссы, но, скажем так, иметь такой маленький триггер, как по мне – полезное дело.

P.S. Напоминаю, что я могу быть не прав, поэтому можно в комментариях все обсудить. Может и норм все называть Service? А это правило только душнит.

😍 😍 😍 А еще, раз уж зашел разговор про комменты, я поделюсь личной эмоцией. Настолько охуенные ваши коммменты, причем абсолютно все. Каждый раз после поста жду, как кто-то что-то напишет, потому что уверен, что там всегда будет что-то новое и интересное. На работе мы часто раньше в корридорах общались на технические темы, где каждый мог свободно вбросить что-то и потом жарко об этом спорить. Из этих разговоров я вытаскивал для себя книги, названия инструментов, подходы, и даже узнавал что-то из смежных областей, таких как мобильная разработка. Сейчас, в силу удаленки, это сильно понерфилось, поэтому когда в тут появлятся дискуссия очень похожая по духу к тому, что я видел в прошлом, у меня прям глаза на слезы наворачиваются (точнее это не слезы, это просто батумский дождь). 😢

🤔 Как хранить в БД объекты с иерархией наследования?

Столкнулся в тралеботе с необходимостью хранить разные типы вопросов:
 
Есть вопросы с вариантами ответов, а есть вопросы, на которые нужно просто написать правильный ответ. У обоих классов есть базовые свойства и отличаются они одним полем. Значит удобно будет отнаследоваться от базового класса.
 
Как такое хранить в базе? Нашел статью, где рассказывается, что такое можно делать на вьюхах. Мне как-то вьюхи не особо нравятся. Даже не знаю почему. Просто не люблю, когда есть какая-то сущность, которая по сути не совсем настоящая. Появляется то, что Дерек Комартен называет indirection (типа непрямолинейность или хз, как это перевести).
 
Короче, погуглил еще, как такое делается. И в Entity Framework используется самый простой и прямой подход – на всю иерархию одна таблица Table Per Hierarchy. И еще используется Table Per Type  и Table Per Concrete Type (которая по сути тот же Table Per Type только с улучшенной производительностью).
 
Сидел читал про это дело и вот что вычитал. Судя по ответам на StackOverflow никто не юзает вьюхи для того чтобы работать с иерархиями наследования. Ну или точнее это не первая польза от них.
 
Так что как будто выбор идет между двумя подходами.
 
❓ Если работали с такой иерархией, то поделитесь, пжлст, какой подход выбрали, и к чему в итоге привело – было удобно или появились какие-то подводные камни?

🍩 Сходил и узнал, как работает благотворительный фонд.

Я очень долго сторонился от донатов во всякую благотворительность. Мне было непонятно, как удается и одновременно помогать кому-то, и платить, к примеру, за аренду помещений и так далее.

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

В общем, чтобы все это понять, я просто решил сходить лично к вот этим ребятам и все эти вопросы задать. Поговорил с одним из волонтеров, правда забыл имя. Но он довольно бодро описал мне как все у них устроено:

1️⃣ Штаб живет на средства, полученные от фонда развития,а не на средства от сборов. То есть все 100 рублей от моего доната пойдут на лекарства. Таким образом разрешается конфликт интересов.

2️⃣ Когда ты делаешь благотворительный проект, то ты по сути питчишь его как стратап на всяких встречах с этими фондами.

3️⃣ На питче ты коммитишься по определенным целям: сколько привлечешь донатов, сколько людей будет пользоваться помощью твоего проекта, уровень, ниже которого не будет падать текучка волонтеров.

4️⃣ Также ты показываешь свой опыт организации подобных проектов или же участия в них. Без этого тебе никто ничего не даст.

5️⃣ Вся эта схема с питчами работает для европейских благотворительных фондов. Есть российские фонды, там распределение средств идет по-другому.

6️⃣ Еще из интересного. Когда был в офисе ребят, то заметил, что они используют какой-то софт для распределения складских остатков. Я честно думал, что это будут просто гугл-таблицы. Но оказалось, что существует целая куча сервисов для благотворительных организаций, управления складами и волонтерами и так далее. К примеру вот такая CRMка для волонтеров. Это круто, потому что вы можете разрабатывать такой софт, получать при этом деньги, и одновременно понимать, что точно делаете что-то полезное.
 
Вообще в процессе разговора у меня сложилось приятное впечатление. Как будто я попал в Додошный офис, где тебе буквально каждый может провести экскурсию и в деталях рассказать, и как что разрабатывается, и как основная бизнес-модель устроена, и подсветит открыто недостатки, если такие имеются. В общем, сложилось ощущение прозрачности.

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

⚾ Специалист по PostgreSQL выдал базу.

Часть 3. Чек-лист оптимизаци запросов

Что вам нужно знать, чтобы понимать, как оптимизировать запросы:

1️⃣ Как читать статистику распрделения данных в БД. Как я понял имеется в виду представление pg_stats.

2️⃣ Есть планировщик и экзекьютор. Планировщик опирается на ту статистику, которая собрана по таблице в pg_stats. По умолчанию он анализирует 30000 строчек. Можно настроить для каждой таблички свой сэмпл. В MySQL есть аналоги.

3️⃣ pg_stats – важные колонки:
🟠n_distinct – количество уникальных значений в одной колонке. К прмеру для булеана понятно, что это значение будет 2.
🟠correlation – упорядоченность данных
🟠null_frac – количество нуллов
🟠most_common_vals – наиболее часто встречающиеся значения (ну типа если у вас таблица с транзакциями, то в этой графе первым значением будет "выполнено")
🟠most_common_freqs – частота их встреч (ну и тут соответственно будет что-то типа 0.99 это для значения "выполнено")

4️⃣ Для анализа запроса желательно вручную собрать сэмпл на 30000 записей, как это делает планировщик.

🫡Интересный факт: Иногда статистика планировщика может быть собрана по неудачному сэмплу, и это просадит запросы. Событие редкое, встречается раз в год, один раз на сто баз.

#postgresql #андрейсальников

⚾ Специалист по PostgreSQL выдал базу.

Часть 4. Типы индексов в постгрессе

🌳 b_tree - самый типичный, работает в 90% случаев.

#️⃣ hash – сейчас по сути бесполезен. Потому что работает медленнее B-tree и нужен был когда-то потому что попросту занимал меньше места.

📐 gist - это индекс для геоданных и геометрии. Раширения: pg_trgm – поиск по регекспам и по лайкам. Btree_gist – сложные constrains с интервалами.

📐 sp_gist – нет практических применений. Это научный индекс. Более гибкий

🪄 gin - может сильно просадить диск, хорош для текстового поиска,

💬 jsonb – jsonb_ops – операция для поиска по большому джсону, json_pat_ops

◾ brin — (индекс сил Альяна, если вы понимаете о чем я) крайне компактный индекс, если данные упорядочены, то мы можем из блока который читаем проиндексировать наименьшее и наибольшее значение. Это как части в фильмах по сути. Мы не знаем, в какой конкретно минуте хоббиты будут бросать кольцо в лаву, но знаем, что не в первой и не во второй частях, так что там можно не искать (это мой ебанутый пример, не автора). Хороший трейдоф между размерами и производительностью.

#postgresql #андрейсальников

⚾ Специалист по PostgreSQL выдал базу.

Часть 5. Indexes Null or Not Null

Про нулловые индексы:

1️⃣ Если у вас есть нуллабельные поля и вы делаете по ним индексы, то делайте индексы с условием is not null. Особенно это пригодится, если вы делаете индекс по Foreign Key

2️⃣ Не забывать создавать ForeignKey это даст ускорение в 2055 раз и уменьшение размера в 14 раз. По умолчанию не создается. И я тут для себя подметил, что пожалуй это единственный индекс, который можно создать прям до того, как в таблицу польются данные.
 
Indexes Partial
1️⃣ Параллелить нагрузки в OLTP базах нельзя. То есть делать так, чтобы несколько потоков выполняли один запрос – это подходит для Аналитических баз, но не для процессинга транзакций – целиться нужно в то чтобы одна транзакция выполнялась как можно быстрее.
 
2️⃣Нужно быть с индексамы аккуратнее.

❌ Вот такой индекс не очень.

create index strange on sometable ((state == 'ожидание'));

Этот индекс будет идти по булевскому значению данного выражения, то есть по трем возможным значениям true false и null (если данных в поле нет). То есть по сути такой индекс будет мало фильтровать данных.
 
✅ Вместо этого стоит создавать индекс по нескольким полям:

create index strange on sometable (created_at) where state != 'обработано'

Это partial index. Офигенная фича так-то, то есть индекс строится не для всех строк таблицы, а только для тех, что указаны в условии. Это компактизирует индекс. К сожалению MySQL не поддерживает эту фичу, но я StackOverflow'ил вот такой обход этой проблемы.
 
3️⃣ Забавно, что вот такой вариант:

create index strange on sometable (created_at, state)

занимает чуть меньше места чем вот такой:

create index strange on sometable (state, created_at)

все дело в том, что такой вариант размажет данные по b-дереву чуть лучше. А разница в выполнении не существенная.

🚴 🔛 🗺 Помощь зала. Курьер на карте.

Помните я писал про то, как устроен курьер на карте? Так вот выяснилось ожидаемое, но то, во что не хотелось верить: Курьер на карте перемещается рывками.

Причины рывков разные: где-то телефон заглючивает, где-то частоты обновлений не хватает, где-то спутник не ловит. Почти уверен, что мы еще словим внезапные перемещения на другую часть земного шара в зоне, где GPS глушится. Но пока не словили.

Так вот. Надо что-то с этим делать, и у нас возникла идея – давайте отрисовывать движение курьера с запозданием в 1 минуту. Ну то есть не сразу рисовать, то, что пришло, а сначала немного подождать следующую точку, а потом плавно сынтерполировать движение от одной точки к другой.

Тут есть нюанс разумеется: если за эту минуту курьер успел повернуть, то интреполированный втупую путь будет выглядеть так, словно курьер летит над домами.

❓ Запрос на помощь зала: Подозреваю, что без простройки пути и привязывания пришедших точек к этому пути не обойтись, но вдруг есть какой-то выход попроще? Вдруг вы где-то видели статьи в интернете о том, как работатет стриминг движения объектов объектов по координатам? И какие подводные камни несет, и как все это можно обойти? Запрашиваю в общем помощь зала, а то я что-то не нагуглил ничего вменяемого 🐈️️️️️️

🐈‍⬛ Да что такое этот ваш Aspire?!

Как только вышел новый .NET я сразу обратил внимание на этот самый Aspire. Как и положено наивному неофиту, я по первости полайкал – можно быстро засетапить проект, не обращая внимания на инфру, и все будет просто работать. Причем со всеми метриками, дашбордами и прочим.

Но ливером я почувствовал что-то неладное 🍑 .

И, пока я размышлял над этой штукой, вышло несколько видосов у Ника Чапсаса (воть и воть), которые как бы еще больше раскручивают дерьмовый маховик хайпа.

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

1️⃣ Если у вас мультиязыковой проект (к примеру Go у вас и Kotlin и C#) и вы хотите наладить в нем Observabilty так, чтобы можно было потрейсать все сервисы, то Apire вам по понятным причинам не подойдет.

2️⃣ Если вы делаете стартап, то, да, эта фиговина позволит вам быстро засетапить все подряд и понять, почему ваш супер-стартап лег на повышенных нагрузках при запуске (это если вам еще повезет такой стратап запустить. Скорее всего вы будете разбираться в причинах того, почему вообще никто не пришел). При этом, если стартапу повезет и он разрастется, то остается опасность того, что Microsoft рано или поздно просто забросят поддержку этого туллинга и вам рано или поздно придется переезжать на графану, ягер и прочие такие штуки. Ну и не факт, что это не будет больно.

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

Пока что я вижу только один реально более-менее подходящий сценарий – это сценарий номер 2️⃣. И то выглядит рисковым на долгосрочном интервале.

Короче, пока что выглядит как та самая штука, которую ты будешь выпиливать, когда придешь новичком на проект через пять лет. И в целом попахивает WCF'ом от этой штуки. Но все же хайпуют? Объясните, что я там не так увидел?

P.S.: А для крутого дашборда по всем вашим сервисам, есть к примеру coroot с охуенной лайв-демкой 🥹

🏭 Fun Fuckt: сколько версий меню нужно для счастья?

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

1️⃣ Посмотрть, кто еще запрашивает старую версию,

2️⃣ Сколько денег все эти запрашивающие приносят,

3️⃣ У кого из запрашивающих все работает корректно, а кто лезет в старую версию, потому что что-то сломалось.

4️⃣ Поглядеть в код андроида, как там реагируют на новую версию менб, поглядеть код iOS, а там как?

5️⃣ Обсудить со всеми до какой версии можно хардапдейтнуть оба приложения, и, когда это можно сделать.

6️⃣ Скрестить пальцы и молиться, чтобы в хардапдейтнутой версии проблем со старой версией меню не было. Реально молиться, потому что этот хардапдейт делается только раз в год в ночь на Ивана Купалу. Если все плохо, то тогда старая версия меню с нами останеться еще на несколько сезонов.

А еще, когда смортю на разницы в версиях, то по ощущениям, будто смотрю на спил дерева – по истории изменений можно просмотреть на то, как менялось наше отношение к продуктам (да и хрен ли там – во многом рынок доставки): вот тут были просто пиццули без заморочек, а тут уже какие-то метапродукты – продукты, которые состоят из каких-то других продуктов. Фракталы, получается.

В общем, если я выпилю что-то не то, на проде в старых мобилках в ночь на Ивана Купалу может появиться кофе на тонком тесте. Так что, если что-то такое увидите, загадывайте желание, делайте скрины) Ну и обновите приложение, что уж там, это только в супер-древних верисях будет.