Это как у нас в геймдеве. Все затирают про отпимизацию логики и прочего, а тормозит обычно всегда UI :D

А какая разница на каком потоке если пользователь вместо того чтобы данные видеть наблюдает анимацию?

При нормальной работе с базой анимация могла бы крутиться условных пол секунды на дешманском девайсе, а крутится вместо этого 5-10 секунд

Ах. В этом смысле. Ну, да, если десятки-сотни запросов из клиента делать без пула, то запросы могут много времени сожрать.

Да даже если делать не по одному запросу за раз а, условно, по восемь, если самих запросов под тысячу - это писец. При том что если бы базу проектировал изначально кто то разбирающийся хотя бы немного - то достаточно было бы одного запроса. А сейчас, спустя полтора года от старта проекта (или два года, хз, я только под этот новый год пришел) полностью базу переделать уже слишком больно.
Зачем то для "чистоты" архитектуры базу еще и разделили на пару десятков баз по 2-4 таблицы, при том что данные между ними нередко связаны. Я конечно надеюсь что руки у меня дойдут это все исправить со временем, но пока все время уходит на пиление фичей и багфиксы

Если делаются тысячи запросов за раз в рамках одного бизнес-процесса, то тут явно что-то не так.

У меня даже на бекенде такого не бывает.

Да у меня скрипты миграций меньше запросов делают))

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

Я собственно сразу и сказал что тут все не так в организации работы с базой. Надо получить список книг в библиотеке пользователя с доп инфой (синхронизирована книга или нет, статус и т.п.). Инфа по книгам, по статусам, по синхронизации хранится не то что в разных таблицах, а разных локальных базах, в результате чего приходится тянуть все в память и уже потом в памяти все это джойнить и фильтровать если надо.

Мне от такой ситуевины довольно больно. Поскольку в свое время по меркам 1с почти хайлоад проекты делал на первой работе и мы там каждый нюанс старались учитывать, и наблюдать такое отношение прям печально.

Напоминаем: 14 июня стартует Podlodka TeamLead Crew!

Да, это уже совсем скоро, в ближайший понедельник. Если остались сомнения, то самое время их развенчать! Ознакомьтесь с подробностями по темам недели, спикерам и билетам на нашем сайте.

🔥Делимся свежаком: в ряду топовых спикеров пополнение! В этот раз вместе с нами Григорий Бакунов (Parimatch). Григорий выступит с темой "Какой должна быть мотивация в команде?"

Ждём вас на борту!

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

Может, как раз потому, что про оптимизации и алгоритмы слышали только "ал", да и то в слове алкоголь?

Хотя в мобилках как раз должны думать про ресурсы как нигде. Потому что "залить железом" просто не получится.

Это кажется @Katella размышлял стоит ли. Имхо, если выбора вакансий нет - действительно стоит. Поскольку опыт программирования, решения проблем вполне норм можно получить при желании и в 1с. И довольно значительный кусок этого опыта можно будет с собой унести.

Да, я)

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

.

Горячо приветствую