Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 12
Лет 8-10 назад кто-то на Holy JS рассказывал случай. Выкатили новую версию игрового сервера на NodeJS, и буквально к вечеру всё стало ужасно тормозить, CPU забился доверху. Стали разбираться. Оказалось в этом релизе выкатили функционал премиум подписки. На объекте юзера звели поле isPremium, которое при конструировании игрока не инициализировалось, а если он покупал премиум, то поле накидывалось со значением true. В итоге небольшой процент юзеров купивший премиум имел другой скрытй класс и при попадании я разные функции то тут то там деоптимизировал их. Добавили в конструктор юзера явную инициализацию поля и вся производительность вернулась.
Можно провокационный вопрос оффтоп. Насколько, на взгляд автора, уместно спрашивать на собеседовании frontend-разработчика вопросы, которые были описаны в его статьях? Есть опасение получить негативный фидбек о токсичности, если начать копать так глубоко и спрашивать о V8-оптимизациях у соискателей. Есть ли у кого-то тут подобный опыт?
Ох, интересный вопрос) Как по мне, это и не каждому бэку нужно. Ну и от позиции зависит. Условный джун, тоже наверное нет, ему бы просто все приколы языка познать.
От мидла+ наверное хорошо бы, чтобы разработчик, хотя бы интересовался, как там язык под капотом работает.
На собеседовании, скорее нет, чем да. Можно затронуть эту тему, но не в разрезе контрольного вопроса, а так, мимоходом. Интересовался, изучал, что то трогал кандидат в этой стороне.
А так же от проекта, команды зависит. Если команда пишет фронт на реакте для crm, тут оно точно не надо. А вот если команда пилит условную молотилку цифр и перекладывалку джисонов на кучу запросов в секунду или мало запросов, но тяжелых, тут дело другое.
В общем, зависит от обстоятельств и настроения обоих участников допроса.
В геймдеве у синьёров я спрашиваю обязательно. Хоть какое-то понятие об этом должно быть. И всех, начиная с джуна спрашиваю: "так случилось, что то, что вы сделали тормозит, в любом смысле этого слова, ваши действия, как вы будете искать проблему?" очень многое говорит о том задумывается ли человек о производительности вообще, как широки и как глубоки его понятия об этом. Концепцию О нотации обязательно даже для джуна в геймдеве.
"так случилось, что то, что вы сделали тормозит, в любом смысле этого слова, ваши действия, как вы будете искать проблему?"
В естественном и убывающем порядке важности:
Выбрал не тот алгоритм/структуру данных; дефекты реализации.
Незнакомая мне особенность языка.
Неправильная/неэффективная технологическая платформа/технология/язык программирования.
Возможно, упустил что-то ещё.
Так, начало есть, а теперь ваши действия, как локализовать проблему?
[ Ну, я даже и не джун... ;-( ]
Во-первых, можно поменять алгоритм. Если, например, речь идёт о сортировке элементов некоторого массива, то на разных данных более быстрыми будут разные алгоритмы. Различие в данных относится и к их размеру (тут в дело вступают константы оценок сложности), и к их содержанию (бывают, так сказать, частично упорядоченные массивы). В случае, если речь идёт, например, о построении матричного профиля временного ряда (это такая функция, которая сопоставляет каждому фрагменту временного ряда расстояние до заданного образца из другого временного ряда: Вы проводите скользящее окно фиксированной ширины/длины вдоль временного ряда и получаете новый временной ряд, который и называется матричным профилем), то его непосредственное вычисление часто оказывается невозможным (слишком много сравнений!), зато имеются техники, позволяющие существенным образом сократить количество сравнений (и вычислять матричный профиль за секунды и минуты против часов и дней).
Во-вторых, можно "прошерстить" сам алгоритм, и проверить правильно его реализации. Можно попытаться переписать его, возможно, выбрав другие структуры данных (с учётом времени доступа и времени обновления структуры). Ещё бывает очень дорогим вызов процедур/функций. Плюс оптимизация компилятора. И не забудем про кеширование в оперативной памяти. А многопоточность? Вот, бывает так, что процесс хочет записать что-то в память, а память ещё не готова принять данные?
В-третьих, (а, точнее, во-первых!), надо всё тщательно измерить. Любое оценочное суждение должно быть подкреплено числом. Запускать надо на разных конфигурациях/машинах. Надо точно знать, точно ли, что это колесо доедет до Москвы, а до Казани не до едет.
По сути тут не про V8 даже. Это буквально база компьютерных наук, того как компьютер представляет данные. Взять тот же C, C++ и сразу станет понятно чем хорошо/плохо смена типа в рантайме.
Так что спросить можно у любого программиста, но учитывая, что сейчас 9 из 10 не могут уверенно назвать разницу между var, let, const - не обязательно)))
К сожалению, вопрос про var, let и const задаётся, как правило, на любом собеседовании, которыми сейчас наполнены YouTube и тематические группы в Telegram. В 2026 году количество людей, которые научились заучивать вопросы на скринингах и подготовлены менторами, увы, превысило возможности HR-отдела по обработке резюме. Тем более что графа «опыт работы» абсолютно девальвировалась и превратилась в фарс. Фактически остаётся только ужесточать требования и спрашивать базу компьютерных наук, но вызывает серьёзные опасения, что на фронтенде такие вопросы вызовут крайне негативную реакцию.
ну я собешу людей, я без шуток говорю, 9 из 10 не может ответить. Даже разницу в области видимости. И это люди которые якобы 5+ лет опыта)
что на фронтенде такие вопросы вызовут крайне негативную реакцию.
Рыночек сейчас не тот. Но вполне можно упустить нормального, если он просто, ну забыл нюансы какие-то, которые в целом и не нужны верстая формочки
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Смена типа в объекте тоже не бесплатна