И если кандидат не прошел, то я ему ставлю отметку - "Не соответствует уровню, заявленному в резюме". Второго шанса у таких кандидатов нет. А ещё работодатель может оставить отзыв на ХХ, который к кандидат не увидит, но этот рейтинг будет влиять на дальнейший подбор вакансий.
Хм... Враньё и использование ИИ. Ну да, ну да. Я провел 200+ собеседований и скажу вам так, что практически любые попытки обмана раскрываются на раз два. Достаточно задать пару нестандартных вопросов или дать небольшую задачку на code review и сразу становится понятно кто перед тобой... Проблема в том, что сегодняшний Джун не хочет сначала поработать за маленькие деньги в ООО Рога и Копыта. Ему надо сразу оверпрайс. Но, простите, с какого? А ваши советы врать могут привести к тому, что кандидат просто попадет в ЧС и второй раз его просто рассматривать не будут! Враньё с самого начала это путь в никуда. Другое дело когда интервьюер такой же бездарь и вот с этого момента начинается деградация ИТ
Я бы посоветовал вам разобраться как происходит сборка банда. Вы же сами пишете, что создаётся рутовый компонент на и основе которого создаются другие компоненты для сторибука + интеграция сервиса с моком и всё это отдается наружу для тестирования. Возникает вопрос - Зачем? Какую задачу вы решаете? Если вы думаете, что у вас будет проблема с вёрсткой, то это решается путем углубленного изучения css. Если вам надо проверять функциональную часть, то для этого пишутся юнит тесты. QA команда должна тестировать вашу разработку только в реальных условиях иначе ценность таких проверок околонулевая. Это уже проверено, сколько бы аккуратно не пишется код, а в реальных условиях всё равно будут отклонения.
Да все ваши варианты один сплошной минус. Изобретаете велосипед там, где не надо. Прозрачности разработки нет. Постоянно надо перед выкаткой удалять, либо жонглировать состоянием что использовать моки или реальные сервисы. Код становится мусорным как раз из-за лишних примесей. Как тестировать сервисы тоже неясно. Из логики поста мне для каждого сервиса необходимо написать N вариантов моков для каждого из случаев! Ах да, заголовок же как раз про 200к LOC Отличная идея выжечь команду на первом же проекте! А всего-то надо взять и подключить msw в режиме разработки и всё Сервисы работают как и задуманы без лишних включений. Нет лишних мок-непонятных компонентов. Код прозрачный и пишется так как он и должен. Моки живут отдельно от продакшнена и их нет в бандле. Тестирование ускоряется за счёт автогенерации...
Сейчас бы в 2025 быть фулстеком, учитывая какое количество требований появилось как на BE, так и на FE. Если склеить две любые вакансии бек/фронт, то уверяю получится список на 2-3 страницы. Чтобы соответствовать всем этим требованиям вам нужно минимум 3-5 лет работы со всем этим барахлом. При этом, что ценник у фулстека не х2. Просто компании хотят вместо двух разработчиков нанять одного универсала...
Вот ничего подобного. Если компонент определен через стрелку на верхнем уровне, то нормально будет отображаться. Проблема будет при возврате из ХОФ, но для этого литер есть, который ругается
Вот как раз на этих языках он реализован нормально, а в JS/TS это огрызок. Да ещё и неявное создание другого объекта под капотом. Значение enum будет являться строгим строковым литералом, а значит ни одно сравнение с переменным вида string работать не будут - потребуется явное приведение в месте использования.
Очень много споров всегда идёт, что же все-таки использовать if или switch. Мы у себя на проекте приняли правило, что если требуется логика выбора по одному значению, то это switch. If используем только для логических выражений и вычислений
Статья - кликбейт. В первую очередь лодаш хейтят потому что неправильно делают импорты функций. И вместо 1кб заезжает в бандл вся библиотека из-за банального import _ from lodash. Во-вторых, перечисленные функции ну не самые интересные, по сравнению с set, pickBy, omitBy и merge. Там ещё много есть интересных функций. Да, многие уже устарели, но часть остаётся востребованной и никто не мешает сделать import omit from 'lodash/omit'...
К сожалению, у нас в стране очень узкий коридор для специалистов на плюсах. Геймдева нет, разработку бека на них тоже почти никто не делает, без qt нормального интерфейса не запилить, остальные фреймворки боль. Остаётся красноглазить на библиотеках и низкоуровневых решениях. Из-за этого перешёл на другие языки - боли меньше, вакансий больше. Из плюсов, простите за каламбур, потом любая типизация и дженерики как семечки
Ну прекратите уже говорит что есть очередь макрозадач. Это всего лишь название, а фактически это не очередь, а набор задач(set) Из статьи в статью копируют, а потом все удивляются, что новички не знают как на самом деле работает event loop. Вот что написано в спецификации "Task queues are sets, not queues, because the event loop processing model grabs the first runnable task from the chosen queue, instead of dequeuing the first task." https://html.spec.whatwg.org/multipage/webappapis.html#definitions-3
И если кандидат не прошел, то я ему ставлю отметку - "Не соответствует уровню, заявленному в резюме". Второго шанса у таких кандидатов нет. А ещё работодатель может оставить отзыв на ХХ, который к кандидат не увидит, но этот рейтинг будет влиять на дальнейший подбор вакансий.
Хм... Враньё и использование ИИ. Ну да, ну да. Я провел 200+ собеседований и скажу вам так, что практически любые попытки обмана раскрываются на раз два. Достаточно задать пару нестандартных вопросов или дать небольшую задачку на code review и сразу становится понятно кто перед тобой... Проблема в том, что сегодняшний Джун не хочет сначала поработать за маленькие деньги в ООО Рога и Копыта. Ему надо сразу оверпрайс. Но, простите, с какого? А ваши советы врать могут привести к тому, что кандидат просто попадет в ЧС и второй раз его просто рассматривать не будут! Враньё с самого начала это путь в никуда. Другое дело когда интервьюер такой же бездарь и вот с этого момента начинается деградация ИТ
Я бы посоветовал вам разобраться как происходит сборка банда. Вы же сами пишете, что создаётся рутовый компонент на и основе которого создаются другие компоненты для сторибука + интеграция сервиса с моком и всё это отдается наружу для тестирования. Возникает вопрос - Зачем? Какую задачу вы решаете?
Если вы думаете, что у вас будет проблема с вёрсткой, то это решается путем углубленного изучения css. Если вам надо проверять функциональную часть, то для этого пишутся юнит тесты. QA команда должна тестировать вашу разработку только в реальных условиях иначе ценность таких проверок околонулевая. Это уже проверено, сколько бы аккуратно не пишется код, а в реальных условиях всё равно будут отклонения.
Да все ваши варианты один сплошной минус. Изобретаете велосипед там, где не надо. Прозрачности разработки нет. Постоянно надо перед выкаткой удалять, либо жонглировать состоянием что использовать моки или реальные сервисы. Код становится мусорным как раз из-за лишних примесей. Как тестировать сервисы тоже неясно. Из логики поста мне для каждого сервиса необходимо написать N вариантов моков для каждого из случаев! Ах да, заголовок же как раз про 200к LOC Отличная идея выжечь команду на первом же проекте!
А всего-то надо взять и подключить msw в режиме разработки и всё Сервисы работают как и задуманы без лишних включений. Нет лишних мок-непонятных компонентов. Код прозрачный и пишется так как он и должен. Моки живут отдельно от продакшнена и их нет в бандле. Тестирование ускоряется за счёт автогенерации...
Сейчас бы в 2025 быть фулстеком, учитывая какое количество требований появилось как на BE, так и на FE. Если склеить две любые вакансии бек/фронт, то уверяю получится список на 2-3 страницы. Чтобы соответствовать всем этим требованиям вам нужно минимум 3-5 лет работы со всем этим барахлом. При этом, что ценник у фулстека не х2. Просто компании хотят вместо двух разработчиков нанять одного универсала...
structuredClone - "Да, да, пошёл я на хер!"
Ещё бы заглянуть в бандлы, собранные с target: es2015 и ниже, тогда у автора инфаркт будет)
Это называется по-другому - я что-то накодил такое, что нормально нельзя покрыть юнит-тестами, но переделывать не буду, т.к. тесты отстой, а я гений!
Бегите из такой разработки. Это хаос и отсутствие системного подхода.
Вот ничего подобного. Если компонент определен через стрелку на верхнем уровне, то нормально будет отображаться. Проблема будет при возврате из ХОФ, но для этого литер есть, который ругается
Вот как раз на этих языках он реализован нормально, а в JS/TS это огрызок. Да ещё и неявное создание другого объекта под капотом. Значение enum будет являться строгим строковым литералом, а значит ни одно сравнение с переменным вида string работать не будут - потребуется явное приведение в месте использования.
Очень много споров всегда идёт, что же все-таки использовать if или switch. Мы у себя на проекте приняли правило, что если требуется логика выбора по одному значению, то это switch. If используем только для логических выражений и вычислений
Ничего интересного. Перед однокурсниками выпендриваться)
Статья - кликбейт. В первую очередь лодаш хейтят потому что неправильно делают импорты функций. И вместо 1кб заезжает в бандл вся библиотека из-за банального import _ from lodash. Во-вторых, перечисленные функции ну не самые интересные, по сравнению с set, pickBy, omitBy и merge. Там ещё много есть интересных функций. Да, многие уже устарели, но часть остаётся востребованной и никто не мешает сделать import omit from 'lodash/omit'...
Для этого есть sentry. Позиция автора статьи понятна, но выглядит как велосипед
Эмм.. а preserve log и unhandled exception breakpoints уже отменили ?
К сожалению, у нас в стране очень узкий коридор для специалистов на плюсах. Геймдева нет, разработку бека на них тоже почти никто не делает, без qt нормального интерфейса не запилить, остальные фреймворки боль. Остаётся красноглазить на библиотеках и низкоуровневых решениях. Из-за этого перешёл на другие языки - боли меньше, вакансий больше. Из плюсов, простите за каламбур, потом любая типизация и дженерики как семечки
От python и аннотации типов до TS и JS один шаг )
Ух, советы 30-летней давности подъехали) Без негатива...
Ну прекратите уже говорит что есть очередь макрозадач. Это всего лишь название, а фактически это не очередь, а набор задач(set) Из статьи в статью копируют, а потом все удивляются, что новички не знают как на самом деле работает event loop. Вот что написано в спецификации "Task queues are sets, not queues, because the event loop processing model grabs the first runnable task from the chosen queue, instead of dequeuing the first task." https://html.spec.whatwg.org/multipage/webappapis.html#definitions-3