А вы меня убеждаете, что то, что есть — хорошо, надо принять как данность эти правила игры.
Кажется по крайней мере я ничего такого не утверждал. Как максимум, я могу сказать что «большинство людей в земле где живу я решили что это хорошо, и если вы тоже хотите тут жить, то надо принимать эти правила игры, легче сделать это если видишь не только минусы, но и плюсы.»
Я уделил целый абзац тому, что для разных людей имеют значение разные вещи. Видимо вам просто не подходит Висбаден.
Я не говорю что вы сделали неправильный выбор и не пытаюсь вас переубедить. Тут вообще не может быть неправильного выбора. Как вы считаете лучше так и правильно для вас. Я просто попытался высказать свою точку зрения тоже.
Германия просто другая. Многие вещи не хуже и не лучше, они просто другие.
Например расскажу свою точку зрения про сервис. Да, всё долго. Да, всё что связано с ручным трудом очень дорого. Да, доставка столика из Икеи за 60 евро стоит сравнимо со столиком, а такси не может себе позволить почти никто (серьезно я не понимаю кто на нём вообще ездит). После Москвы где я вызывал минимум комфорт+ не особо глядя на цену это конечно дико.
Но у этого есть обратная сторона, тут совсем другой темп жизни. Я с ужасом вспоминаю Москву именно из-за темпа жизни. В Москве люди в метро ходят быстро. Едят быстро. Работают много и быстро. Везде принцип делать больше и быстрее или умрёшь с голоду. Также как многие в комментариях я работал с третьего курса, а на шестом (МГТУ) работал фуллтайм 40 часов в неделю. Тут никто не спешит. Заканчиваешь работать во время и спокойно едешь на велосипеде домой. Проводишь время с семьёй.
Да нельзя заказать айфон с доставкой на сегодня, а велосипед мне вообще пришлось ждать 3 недели (и это ещё повезло). Но помните что за каждым удобством и быстрым сервисом который вам нравится стоит кто-то кто это делает. За доставкой продуктов 24 часа в сутки за 15 минут стоят курьеры работающие круглосуточно и возможно не видящие семью неделями. И где-то в этом цикле, скорее всего, тем или иным образом, крутитесь и вы, ведь вы же не только клиент, но и как минимум 8 часов в день сотрудник. А в Мюнхене (1.5 миллиона человек население) в воскресенье работает только три продуктовых магазина и один из них в аэропорту. И работать в воскресенье не разрешает закон, хотя сети вроде как были бы рады открыться хоть круглосуточно. Просто все решили что лучше каждый будет немного страдать от не такого классного сервиса, но зато и сам будет жить свободнее и в конечном счёте лучше.
Да везде термины (сложно перевести, наверное самое точное записи и талоны). Мне нужно обслужить велосипед в конце сезона и я не нашёл ни одного свободного «окошка» до ноября. Но просто тут никто не спешит и планируют заранее.
Да ждать врача, если у вас нет ничего срочного, 3-4 недели, но так ведь у вас и нет ничего срочного. Запишитесь и ждите. Просто люди живут с другим горизонтом планирования. Если ты знаешь, что тебе надо два раза в год ходить к зубному, то просто записываешься сразу на апрель и ноябрь следующего года. А если что-то срочное то в госпитале помогут. Мне сделали экстренную операцию меньше чем через сутки после обращения в госпиталь. Качество медицины точно не хуже бесплатной медицины в Москве. И плановой и экстренной, мы успели попользоваться обеими.
Да, я знаю что я очень много идеализирую, и да я не хочу сказать что автор не прав. Просто пытаюсь объяснить что многие вещи не лучше и не хуже, они просто другие. Я вообще так сформулировал своё видение эмиграции: разные страны имеют разные особенности (и одна и та же особенность может быть плюсом или минусом для разных людей), а разные люди разные приоритеты и разные взгляды на то как нужно жить. Просто выбирайте страну где совпадение с вашим мировоззрением наибольшее.
У нас есть старая семейная история. Много лет назад мы приехали в отпуск в Египет, ещё когда это было можно. Вылетали в субботу с утра, после рабочей недели. Весь день перелёт, переезд на автобусе, заселение и вот приходим в ресторан, а там шведский стол. Мы набрали какой-то еды, соков и (как я потом оценил) минут за 5-7 всё это в себя покидали и собираемся куда-то идти дальше что-то делать. Глядя на это не выдерживает официант, приносит нам два бокала вина, показывает на море, на звёзды и говорит (по русски) «не надо бежать, сядь, посиди отдохни». Он потом рассказал что тех кто приехал из Москвы видно за версту именно по темпу с которым они всё делают. Для меня Германия это такое «не надо бежать» растянутое во времени в бесконечность.
Code Review это процедура когда изменения прежде чем попасть в мастер оформляется в пакет (Pull Request, Merge Request, Change List) и проходит проверку одним или несколькими другими программистами этого же проекта.
Позволяет поддерживать хорошее качество кода и на ходу исправлять ошибки\улучшать архитектуру, т.к. при решении задачи часто код проходит через несколько итераций и глаз уже «замыливается», свежий взгляд коллеги часто позволяет что-то улучшить ну или хотя бы поправить косяки.
Можете сами попробовать в почти любом опенсорсном проекте на гитхабе. Чаще всего там есть список задач отмеченных чем-то вроде «Good first task» — несложные задачи которые позволяет разобраться в проекте. Исправляете ошибку\добавляете функционал и делаете ПР. Ждёте прохождения ревью, исправляете недочёты и ваш код в мастере.
Это все равно ухудшит пользовательский опыт. Если вы добавите листнер на скролл, особенно если это НЕ 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 это зло и отхватил столько минусов в карму, сколько плюсов мне ни одна статья не приносила. С тех пор я не пишу комментарии к «острым» темам да и вообще к социальной составляющей хабра охладел и почти ни к чему не пишу.
Кажется по крайней мере я ничего такого не утверждал. Как максимум, я могу сказать что «большинство людей в земле где живу я решили что это хорошо, и если вы тоже хотите тут жить, то надо принимать эти правила игры, легче сделать это если видишь не только минусы, но и плюсы.»
Я уделил целый абзац тому, что для разных людей имеют значение разные вещи. Видимо вам просто не подходит Висбаден.
Я не говорю что вы сделали неправильный выбор и не пытаюсь вас переубедить. Тут вообще не может быть неправильного выбора. Как вы считаете лучше так и правильно для вас. Я просто попытался высказать свою точку зрения тоже.
Например расскажу свою точку зрения про сервис. Да, всё долго. Да, всё что связано с ручным трудом очень дорого. Да, доставка столика из Икеи за 60 евро стоит сравнимо со столиком, а такси не может себе позволить почти никто (серьезно я не понимаю кто на нём вообще ездит). После Москвы где я вызывал минимум комфорт+ не особо глядя на цену это конечно дико.
Но у этого есть обратная сторона, тут совсем другой темп жизни. Я с ужасом вспоминаю Москву именно из-за темпа жизни. В Москве люди в метро ходят быстро. Едят быстро. Работают много и быстро. Везде принцип делать больше и быстрее или умрёшь с голоду. Также как многие в комментариях я работал с третьего курса, а на шестом (МГТУ) работал фуллтайм 40 часов в неделю. Тут никто не спешит. Заканчиваешь работать во время и спокойно едешь на велосипеде домой. Проводишь время с семьёй.
Да нельзя заказать айфон с доставкой на сегодня, а велосипед мне вообще пришлось ждать 3 недели (и это ещё повезло). Но помните что за каждым удобством и быстрым сервисом который вам нравится стоит кто-то кто это делает. За доставкой продуктов 24 часа в сутки за 15 минут стоят курьеры работающие круглосуточно и возможно не видящие семью неделями. И где-то в этом цикле, скорее всего, тем или иным образом, крутитесь и вы, ведь вы же не только клиент, но и как минимум 8 часов в день сотрудник. А в Мюнхене (1.5 миллиона человек население) в воскресенье работает только три продуктовых магазина и один из них в аэропорту. И работать в воскресенье не разрешает закон, хотя сети вроде как были бы рады открыться хоть круглосуточно. Просто все решили что лучше каждый будет немного страдать от не такого классного сервиса, но зато и сам будет жить свободнее и в конечном счёте лучше.
Да везде термины (сложно перевести, наверное самое точное записи и талоны). Мне нужно обслужить велосипед в конце сезона и я не нашёл ни одного свободного «окошка» до ноября. Но просто тут никто не спешит и планируют заранее.
Да ждать врача, если у вас нет ничего срочного, 3-4 недели, но так ведь у вас и нет ничего срочного. Запишитесь и ждите. Просто люди живут с другим горизонтом планирования. Если ты знаешь, что тебе надо два раза в год ходить к зубному, то просто записываешься сразу на апрель и ноябрь следующего года. А если что-то срочное то в госпитале помогут. Мне сделали экстренную операцию меньше чем через сутки после обращения в госпиталь. Качество медицины точно не хуже бесплатной медицины в Москве. И плановой и экстренной, мы успели попользоваться обеими.
Да, я знаю что я очень много идеализирую, и да я не хочу сказать что автор не прав. Просто пытаюсь объяснить что многие вещи не лучше и не хуже, они просто другие. Я вообще так сформулировал своё видение эмиграции: разные страны имеют разные особенности (и одна и та же особенность может быть плюсом или минусом для разных людей), а разные люди разные приоритеты и разные взгляды на то как нужно жить. Просто выбирайте страну где совпадение с вашим мировоззрением наибольшее.
У нас есть старая семейная история. Много лет назад мы приехали в отпуск в Египет, ещё когда это было можно. Вылетали в субботу с утра, после рабочей недели. Весь день перелёт, переезд на автобусе, заселение и вот приходим в ресторан, а там шведский стол. Мы набрали какой-то еды, соков и (как я потом оценил) минут за 5-7 всё это в себя покидали и собираемся куда-то идти дальше что-то делать. Глядя на это не выдерживает официант, приносит нам два бокала вина, показывает на море, на звёзды и говорит (по русски) «не надо бежать, сядь, посиди отдохни». Он потом рассказал что тех кто приехал из Москвы видно за версту именно по темпу с которым они всё делают. Для меня Германия это такое «не надо бежать» растянутое во времени в бесконечность.
Позволяет поддерживать хорошее качество кода и на ходу исправлять ошибки\улучшать архитектуру, т.к. при решении задачи часто код проходит через несколько итераций и глаз уже «замыливается», свежий взгляд коллеги часто позволяет что-то улучшить ну или хотя бы поправить косяки.
Можете сами попробовать в почти любом опенсорсном проекте на гитхабе. Чаще всего там есть список задач отмеченных чем-то вроде «Good first task» — несложные задачи которые позволяет разобраться в проекте. Исправляете ошибку\добавляете функционал и делаете ПР. Ждёте прохождения ревью, исправляете недочёты и ваш код в мастере.
Это все равно ухудшит пользовательский опыт. Если вы добавите листнер на скролл, особенно если это НЕ 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 это зло и отхватил столько минусов в карму, сколько плюсов мне ни одна статья не приносила. С тех пор я не пишу комментарии к «острым» темам да и вообще к социальной составляющей хабра охладел и почти ни к чему не пишу.