Это все равно ухудшит пользовательский опыт. Если вы добавите листнер на скролл, особенно если это НЕ passive listener браузеру придется дожидаться ответа от JS на каждый скролл что ухудшит плавность скроллинга. Даже если этот листнер будет просто делать return потому что он затроттлен. Подход с IntersectionObserver на имеет влияния на плавность скролла.
Вторая проблема: элемент может появиться на экране не только из-за скролла, но и по другим причинам. Самое частое: ресайз окна и удаление элементов из дерева, приводящее к сдвигу нижних элементов вверх. В традиционном подходе вам придется вручную вызывать какой-то хэндлер проверяющий не появилось ли что-то нового во вью порте во всех этих случаях, что опять же во первых лишняя работа, во вторых может быть нетривиально в случае если есть цепочка асинхронных вызово, и в третьих может приводить к force relayout если вы сделаете это синхронно.
Да большую часть этих проблем можно решить сделав, например класс который аккамулирует триггеры которые могут привести к необходимости догрузки данных и проверяет реальную необходимость через requestAnimationFrame + использовать только passive листенеры стролла и ресайза, но тогда вы фактически изобретете IntersectionObserver.
И ещё одна мысль которая кажется уже была высказана, но не лишним будет повторить.
Одностраничное резюме это фактически отраслевой стандарт. Просто математически на этапе резюме-фильтра намного больше шансов пройти дальше с одностраничным резюме чем с рассказом о себе на 5 листов. Поэтому все подгоняют свои резюме под это универсальный стандарт. Пять страниц многие даже не будут читать. Какое-то время назад было исследование конверсии ссылок в резюме в переходы на гитхаб, и процент там был драматически низкий. На самом деле вы молодцы что так подробно изучаете резюме.
Если вы построили свой процесс таким образом, что хотите проводить техническое интервью только после какого-то более менее тщательного предварительного отбора, то в этом нет ничего плохого, даже скорее хорошо, но как кандидату об этом узнать?
Выход очень простой — проводите короткие скайп созвоны или отправляйте опросник с максимально открытыми вопросами. Можете даже упомянуть что предпочтительно было бы получить ответ в методологии STAR (про нее было выше).
Если добавите в этот запрос немного персонализации вида "уважаемый кандидат, нам интересен ваш опыт в технологии Х который вы указали в своем резюме, для того чтобы мы могли подговиться к следующему этапу заполните пожалуйста эту анкету", чтобы было понятно что отвечает не робот, то думаю будет достаточно высокая конверсия в ответы.
Главное это чтобы все участники понимали что от них ожидает другая стророна. А вы отсеиваете тех кто не знает о ваших, отличающихся от большинства компаний, требованиях вместо того чтобы просто эти требования уточнить.
Вам не хватает научного подхода. Для того чтобы что-то утверждать надо иметь хоть что-нибудь кроме своего мнения.
Хотя бы провести простейший эксперимент вида "мы взяли 10 кандидатов резюме которых нам понравилось и 10 тех кого забраковали по причине недостаточного раскрытия soft skills в резюме. Затем пригласили их на интервью и по результатам выяснилось, что те, кто не умеют развернуто описывать свои навыки и достижения в резюме оказываются мрачными социопатами без надежды на социализацию в команде, а те кто могут подробно раскрыть свой опыт в Cover Letter наоборот показывают более высокий уровень soft skills и технических компетенций. Тоже самое подтверждается долей прошедших испытательный срок среди той и другой группы".
А так голословные утверждения про то что вам скучно одинаковые резюме читать.
Я посмотрел сейчас, на экран 13" макбука влезает около 40 строк кода. Это очень много для одного метода, на мой взгляд. Но в целом это конечно же дело вкуса и договоренности в рамках команды.
1. Кажется именно в этом месте происходит несовпадение взглядов. Мой поинт в том что если вы не предполагаете что вы или кто-то будет изменять эту переменную, то надо это запретить. Если вы разрешили то надо уделить этому внимание и подумать об этом. Но в большинстве случаев это не нужно и проще подумать об этом в тот момент когда необходимость возникнет. В этот момент у вас будет больше данных о том, что нужно сделать.
2. Да, честно говоря достаточно редко приходится точечно исправлять код (если это не багофикс). Такое что приходится прийти в какой-то метод и дописать пару строк не часто бывает. Чаще всего заменять какими-то блоками\компонентами, ну или как минимум функциями. При этом зачастую приходится провести какой-то нанорефакторинг в рамках которого исправить let на const или наоборот не составляет труда.
3. Чтение const упрощает значительно. Читая метод можно просто запомнить что в такой-то переменной лежит то-то и не думать об этом. Если переменная let то приходится держать в голове что там что-то может измениться.
Я в целом прекрасно вас понимаю, и некоторое время назад считал также как вы, но попробовал и проникся. Дело в том что вы относитесь к const как к чему-то особенному. Т.е. «по умолчанию переменные надо создавать как let, а const надо помечать только константы которые точно не должны меняться, выделять их таким образом» или что-то вроде того. А вы попробуйте применить этот подход на практике и увидите что почти все переменные в вашей программе можно объявить как const. И в этот момент произойдет сдвиг в сознании и осознание того факта, что на самом деле const это модификатор по умолчанию, и только редкие, единичные переменные должны быть помечены как let. И именно они должны привлекать внимание и вызывать настороженность, а не наоборот.
Ну и в конце я хотел бы заметить что на этот вопрос конечно же нет правильного ответа и это просто вопрос подхода и договоренности в команде, но я рекомендовал бы вам попробовать такой стиль.
Если вы не планируете её менять, зачем писать код с учетом этого? В 90% (оценочное суждение из головы) случаев никто ваш код трогать не будет никогда. В 9.5% случаев его удалят целиком не читая, и только в 0.5% случаев ваша работа проделанная для «подготовки переменной к последующему использованию» окажется полезна. А значит в 99.5% случаев вы делали лишнюю работу.
Мой опыт говорит о том, что код должен хорошо делать то, что от него требуется и предусматривать расширение в тех направлениях которые уже запланированы или хотя бы точно известны. Проектировать в рассечете на то что может понадобиться тут или там как правила не требуется, т.к. результат оказывается переусложенным и избыточным, и время потрачено лишнее.
Я не понимаю о чем мы спорим. В вашем комментарии вы говорите что у вас замыкания чистые и не портят внешние переменные. Но ведь это отлично, я тут вас готов только поддержать. В такой ситуации нет необходимость объявлять переменные let если вы всеравно их не меняете, объявляйте const.
на хотябы одну строчку кода) уже 7 значимых строк кода (не считая пустые). Мне кажется не стоит писать методы в которых больше восьми, ну максимум десяти, значимых строк. Лучше выделять из них дочерние функции. А в небольшой функции и запутаться сложнее.
В целом вопрос написания const по дефолту мне напоминает холивар о написании классов final по дефолту. Суть идеи состоит в том, что класс для того чтобы его можно было эффективно наследовать должен быть заранее подготовлен к этому на этапе дизайна. Человек который пишет класс должен подумать о том как его будут наследовать и расширять. Если он об этом не думал (не было такой задачи) надо ставить final и такой класс не наследовать. Если понадобится то вернуться, передизайнить и убрать final.
Также и с const. Чтобы переменную можно было в любой момент брать и менять нужно заранее об этом подумать, чтобы нельзя было перевести приложение в некорректное состояние. Если программист об этом не подумал, следует объявить переменную const. Если кому-то понадобится её менять, пусть придет, подумает и поставит let.
Задача как мне кажется довольно простая, при этом очень муторная. В ней много корнер кейсов которые надо дополнительно обрабатывать (например не специфицирована операция «поворота по часовой стрелке» матрицы 1xN или Nx1 которая обязательно появится для неквадратной матрицы). Никакой специфичной структуры данных для такой задачи не могу придумать, кажется достаточно определить функцию трансформации координат что-то вроде transformXY(sizeX, sizeY, x, y) -> {x, y} (псевдокод) а затем обойти матрицу «по слоям» от краев к центру, свапая элементы. Так мы получим О(1) по памяти и О(NxM) по времени что кажется является теоретическим пределом (нельзя потратить памяти меньше константной, нельзя провернуть матрицу не потрогав каждый её элемент).
Но на пути к рабочему решению лежит бесчисленное множество граблей, минус единиц, и прочих <\<= требующих сильной концентрации и внимательности.
Мне кажется что это не очень хорошая задача для собеседования, потому что по ней не очень много можно понять о кандидате. Как уже говорили выше, её может решить студент первокурсник, а может накосячить опытный разработчик.
К сожалению имея карму меньше хотя бы 10-20 пунктов нельзя относиться к ней философски. Падение с 502 до 462 (-40 сейчас составляет падение кармы у AWSVladimir) это повод задуматься и получить урок. Падение кармы с -16 до -56 это потерять возможность писать комментарии и статьи, а значит возможность нарастить карму, т.е. фактически потерять аккаунт.
Ваши слова про «получил хороший урок» это своего рода лицемерие, т.к. вы «просто получили урок» именно потому что являетесь администратором ресурса. Простому пользователю этот урок обошелся бы в потерю аккаунта. Это ведет к сильнейшей самоцензуре.
Предложил бы вам попробовать командой зарегистрировать «нулевые» анонимные аккаунты без какой-либо привязки к TechMedia и пожить с ними какое-то время чтобы оценить как реально работает карма.
Статья приносит почти ничего в плане кармы, а за один неудачный комментарий человека могут полностью слить.
Тут проблема в разделении рейтинга и кармы. В голове у людей работает так:
1. Оценка контента это мое отношение к статье или комментарию
2. Оценка кармы это мое отношение к человеку лично
В итоге
1. Если ты написал лучшую в мире статью тебе поставят много плюсов к статье (в рейтинг) и посчитают свою миссию выполненной.
2. Если ты написал комментарий который «не попадет в струю» то тебе минусанут комментарий, да ещё и человек ты видимо так себе раз так считаешь поэтому на тебе и в карму.
Посмотрите на комментарий в начале ветки. Там карму слили с -18 (самое больше что я видел) до -46, это почти 30 минусов. Я не уверен что со времен когда убрали кнопку «плюсануть карму» в футере статьи кто-то набирал столько плюсов за одну статью, а тут слили за один комментарий. А, простите, за что? За то что «резонирует»? Что там такого написано на -30 кармы? Минусовали так сильно, на мой взгляд, только за то что:
1. Написано в топе у всех на глазах
2. Отметился deniskin и сказал что он минусанул, а он авторитет.
Я вляпался в это когда пытался отстоять свою точку зрения, о том что блокировщики рекламы типа AdBlock это зло и отхватил столько минусов в карму, сколько плюсов мне ни одна статья не приносила. С тех пор я не пишу комментарии к «острым» темам да и вообще к социальной составляющей хабра охладел и почти ни к чему не пишу.
Это все равно ухудшит пользовательский опыт. Если вы добавите листнер на скролл, особенно если это НЕ passive listener браузеру придется дожидаться ответа от JS на каждый скролл что ухудшит плавность скроллинга. Даже если этот листнер будет просто делать return потому что он затроттлен. Подход с IntersectionObserver на имеет влияния на плавность скролла.
Вторая проблема: элемент может появиться на экране не только из-за скролла, но и по другим причинам. Самое частое: ресайз окна и удаление элементов из дерева, приводящее к сдвигу нижних элементов вверх. В традиционном подходе вам придется вручную вызывать какой-то хэндлер проверяющий не появилось ли что-то нового во вью порте во всех этих случаях, что опять же во первых лишняя работа, во вторых может быть нетривиально в случае если есть цепочка асинхронных вызово, и в третьих может приводить к force relayout если вы сделаете это синхронно.
Да большую часть этих проблем можно решить сделав, например класс который аккамулирует триггеры которые могут привести к необходимости догрузки данных и проверяет реальную необходимость через requestAnimationFrame + использовать только passive листенеры стролла и ресайза, но тогда вы фактически изобретете IntersectionObserver.
И ещё одна мысль которая кажется уже была высказана, но не лишним будет повторить.
Одностраничное резюме это фактически отраслевой стандарт. Просто математически на этапе резюме-фильтра намного больше шансов пройти дальше с одностраничным резюме чем с рассказом о себе на 5 листов. Поэтому все подгоняют свои резюме под это универсальный стандарт. Пять страниц многие даже не будут читать. Какое-то время назад было исследование конверсии ссылок в резюме в переходы на гитхаб, и процент там был драматически низкий. На самом деле вы молодцы что так подробно изучаете резюме.
Если вы построили свой процесс таким образом, что хотите проводить техническое интервью только после какого-то более менее тщательного предварительного отбора, то в этом нет ничего плохого, даже скорее хорошо, но как кандидату об этом узнать?
Выход очень простой — проводите короткие скайп созвоны или отправляйте опросник с максимально открытыми вопросами. Можете даже упомянуть что предпочтительно было бы получить ответ в методологии STAR (про нее было выше).
Если добавите в этот запрос немного персонализации вида "уважаемый кандидат, нам интересен ваш опыт в технологии Х который вы указали в своем резюме, для того чтобы мы могли подговиться к следующему этапу заполните пожалуйста эту анкету", чтобы было понятно что отвечает не робот, то думаю будет достаточно высокая конверсия в ответы.
Главное это чтобы все участники понимали что от них ожидает другая стророна. А вы отсеиваете тех кто не знает о ваших, отличающихся от большинства компаний, требованиях вместо того чтобы просто эти требования уточнить.
Вам не хватает научного подхода. Для того чтобы что-то утверждать надо иметь хоть что-нибудь кроме своего мнения.
Хотя бы провести простейший эксперимент вида "мы взяли 10 кандидатов резюме которых нам понравилось и 10 тех кого забраковали по причине недостаточного раскрытия soft skills в резюме. Затем пригласили их на интервью и по результатам выяснилось, что те, кто не умеют развернуто описывать свои навыки и достижения в резюме оказываются мрачными социопатами без надежды на социализацию в команде, а те кто могут подробно раскрыть свой опыт в Cover Letter наоборот показывают более высокий уровень soft skills и технических компетенций. Тоже самое подтверждается долей прошедших испытательный срок среди той и другой группы".
А так голословные утверждения про то что вам скучно одинаковые резюме читать.
2. Да, честно говоря достаточно редко приходится точечно исправлять код (если это не багофикс). Такое что приходится прийти в какой-то метод и дописать пару строк не часто бывает. Чаще всего заменять какими-то блоками\компонентами, ну или как минимум функциями. При этом зачастую приходится провести какой-то нанорефакторинг в рамках которого исправить let на const или наоборот не составляет труда.
3. Чтение const упрощает значительно. Читая метод можно просто запомнить что в такой-то переменной лежит то-то и не думать об этом. Если переменная let то приходится держать в голове что там что-то может измениться.
Я в целом прекрасно вас понимаю, и некоторое время назад считал также как вы, но попробовал и проникся. Дело в том что вы относитесь к const как к чему-то особенному. Т.е. «по умолчанию переменные надо создавать как let, а const надо помечать только константы которые точно не должны меняться, выделять их таким образом» или что-то вроде того. А вы попробуйте применить этот подход на практике и увидите что почти все переменные в вашей программе можно объявить как const. И в этот момент произойдет сдвиг в сознании и осознание того факта, что на самом деле const это модификатор по умолчанию, и только редкие, единичные переменные должны быть помечены как let. И именно они должны привлекать внимание и вызывать настороженность, а не наоборот.
Ну и в конце я хотел бы заметить что на этот вопрос конечно же нет правильного ответа и это просто вопрос подхода и договоренности в команде, но я рекомендовал бы вам попробовать такой стиль.
Мой опыт говорит о том, что код должен хорошо делать то, что от него требуется и предусматривать расширение в тех направлениях которые уже запланированы или хотя бы точно известны. Проектировать в рассечете на то что может понадобиться тут или там как правила не требуется, т.к. результат оказывается переусложенным и избыточным, и время потрачено лишнее.
В целом вопрос написания const по дефолту мне напоминает холивар о написании классов final по дефолту. Суть идеи состоит в том, что класс для того чтобы его можно было эффективно наследовать должен быть заранее подготовлен к этому на этапе дизайна. Человек который пишет класс должен подумать о том как его будут наследовать и расширять. Если он об этом не думал (не было такой задачи) надо ставить final и такой класс не наследовать. Если понадобится то вернуться, передизайнить и убрать final.
Также и с const. Чтобы переменную можно было в любой момент брать и менять нужно заранее об этом подумать, чтобы нельзя было перевести приложение в некорректное состояние. Если программист об этом не подумал, следует объявить переменную const. Если кому-то понадобится её менять, пусть придет, подумает и поставит let.
Воды больше чем в моем дипломе.
Предложу свой вариант: "всегда используйте const, кроме случаев когда не можете, тогда используйте let"
transformXY(sizeX, sizeY, x, y) -> {x, y}(псевдокод) а затем обойти матрицу «по слоям» от краев к центру, свапая элементы. Так мы получимО(1)по памяти иО(NxM)по времени что кажется является теоретическим пределом (нельзя потратить памяти меньше константной, нельзя провернуть матрицу не потрогав каждый её элемент).Но на пути к рабочему решению лежит бесчисленное множество граблей, минус единиц, и прочих
<\<=требующих сильной концентрации и внимательности.Мне кажется что это не очень хорошая задача для собеседования, потому что по ней не очень много можно понять о кандидате. Как уже говорили выше, её может решить студент первокурсник, а может накосячить опытный разработчик.
Ваши слова про «получил хороший урок» это своего рода лицемерие, т.к. вы «просто получили урок» именно потому что являетесь администратором ресурса. Простому пользователю этот урок обошелся бы в потерю аккаунта. Это ведет к сильнейшей самоцензуре.
Предложил бы вам попробовать командой зарегистрировать «нулевые» анонимные аккаунты без какой-либо привязки к TechMedia и пожить с ними какое-то время чтобы оценить как реально работает карма.
Тут проблема в разделении рейтинга и кармы. В голове у людей работает так:
1. Оценка контента это мое отношение к статье или комментарию
2. Оценка кармы это мое отношение к человеку лично
В итоге
1. Если ты написал лучшую в мире статью тебе поставят много плюсов к статье (в рейтинг) и посчитают свою миссию выполненной.
2. Если ты написал комментарий который «не попадет в струю» то тебе минусанут комментарий, да ещё и человек ты видимо так себе раз так считаешь поэтому на тебе и в карму.
Посмотрите на комментарий в начале ветки. Там карму слили с -18 (самое больше что я видел) до -46, это почти 30 минусов. Я не уверен что со времен когда убрали кнопку «плюсануть карму» в футере статьи кто-то набирал столько плюсов за одну статью, а тут слили за один комментарий. А, простите, за что? За то что «резонирует»? Что там такого написано на -30 кармы? Минусовали так сильно, на мой взгляд, только за то что:
1. Написано в топе у всех на глазах
2. Отметился deniskin и сказал что он минусанул, а он авторитет.
Я вляпался в это когда пытался отстоять свою точку зрения, о том что блокировщики рекламы типа AdBlock это зло и отхватил столько минусов в карму, сколько плюсов мне ни одна статья не приносила. С тех пор я не пишу комментарии к «острым» темам да и вообще к социальной составляющей хабра охладел и почти ни к чему не пишу.
Вот тут toster.ru/q/584577 например есть текст письма и обсуждение
Спасибо, я просто в поезде с телефона набирал комментарии, не нашел в себе сил искать ссылки :-)