Критерии и система оценок на JS lvl.1

[Spearance]

Предлагаю обсудить и пересмотреть критерии и систему оценок на курсе.

Что сейчас считаю не логичным:
— код работает, но переменные названы как-то не по ГОСТу
мы рубим как-будто это грубейшее нарушение, а это всего лишь договоренность, вытекшая из социальных парадигм.

— неправильно используемое API дополнительный критерий
https://up.htmlacademy.ru/javascript/16/criteries#advanced-8
или это:
— отсутствуют потенциально некорректные операции
https://up.htmlacademy.ru/javascript/16/criteries#advanced-9

Так же было бы логично давать за дополнительные задания больше баллов, иначе пропадает стимул их выполнять

[o0]

@zeckson, @AntonovIgor, @kicumkicum Авторы привет. Нужна дискуссия, давайте обсудим.

[zeckson]

Я согласен.
У меня была идея все доп задания превратить в пункты критериев. Хочется чтобы 100% — было действительно 100%, а не все подряд.

Так же было бы логично давать за дополнительные задания больше баллов, иначе пропадает стимул их выполнять

Согласен на все сто, но т.к. сейчас все пункты равновзвешаны, то единственный способ это сделать — добавить несколько пунктов.

@Spearance на самом деле нам ребята сделали какую-то более-менее статистику на основе которой можно вообще пересмотреть все критерии, например, выкинуть все критерии которые всегда зачтены у всех.

[Spearance]

например, выкинуть все критерии которые всегда зачтены у всех

@zeckson это будет просто праздник какой-то

Еще, было бы неплохо подумать над двумя вещами:

1. Оценке невыполненного ТЗ. Есть случай кода один-два незначительных пункта, а есть когда в принципе не работает и глобально, когда надо ставить вопрос о компетентности наставника. В прошлом потоке я зарубил проект первый раз, но попытки были два или три раза и только куратор вытягивал ситуацию. Если проект совсем не готов, нужно снять с наставника обязанность проверять весь код, ведь большая его часть будет в процессе изменена и это будет мартышкин труд.
   Да, и возвращаясь к системе подсчета, если ТЗ не готово, то свои 48% ты так или эдак получишь — это странно.

2. Юзабильность критериев при проверке. Реально задалбывает листать туда-сюда. Нужно думать над вариантами.

[Drewtsure]

@Spearance немного влезу в ваше обсуждение, так как есть вопрос, который больше относится к кураторам, чем к преподавателям.

Юзабильность критериев при проверке. Реально задалбывает листать туда-сюда. Нужно думать над вариантами.

Мы запустили на текущем потоке интенсива «HTML и CSS, уровень 1» новый интерфейс интенсивов, чтобы протестировать его и доработать. В ближайшем будущем он будет включён на всех интенсивах. В нём в том числе уже переработан процесс проверки случайных проектов.

[AntonovIgor]

Случайно пропустил обсуждение. Мне нравится идея, которую сказал @zeckson - доп. задания должны быть в виде критериев. Тогда оценка будет более релевантная. Этот вопрос уже поднимался, кстати.

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

[balesniy]

Я заметил, что студенты у которых проблемы с именами, обычно не понимают, что именно делает функция или что хранится в переменной. Пишут рядом комментарии, которые противоречат именам. И для них разобраться с именами означает разобраться в собственном коде. А базовый критерий это реальная мотивация.

Если я правильно понял, нам сейчас доступна возможность подвигать/добавить критерии.

Я бы хотел Б10 про константы из раздела "внешний вид" в допы к Д20, они как будто вместе работают.

Б24+Б25 возможно тоже в допы, студенты не успевают с алгоритмами разобраться, приходится готовые решения отдавать для защиты, а Д8+Д9 в базовые, поддерживаю.

Встроенные методы массивов просят отдельного критерия. И я бы туда добавил пример как не надо - когда мы берем forEach и делаем push вместо map.
А "используются по назначению" расширить бы на все методы отдельным критерием, как пример replace с колбэком для перебора символов строки.

Д25 про Длинные функции можно перенести в ESLint с max-lines-per-function, и очень хочется принудительно ограничить длину строки))

Вообще как вы смотрите на расширение правил eslint конфига в сторону автоматических проверок доп критериев? Наставникам проще будет, студенты вроде когда с ограничением сталкиваются неизбежно начинают разбираться что это и зачем. Они конечно допы, вроде как необязательны, но тот же consistent-return у нас включен.

[AntonovIgor]

Я заметил, что студенты у которых проблемы с именами, обычно не понимают, что именно делает функция или что хранится в переменной. Пишут рядом комментарии, которые противоречат именам. И для них разобраться с именами означает разобраться в собственном коде. А базовый критерий это реальная мотивация.

У нас есть критерий, который говорит, что переменные должны быть существительными, а функции глаголами. Мне кажется этого более, чем достаточно. По идее наставники должны за этим следить и во время проверок (домашек) давать студентам рекомендации по неймингу. Если расширить формулировку критерия, то может получиться так, что на нем будут заворачивать по каким-то субъективным причинам.

Мне кажется, что с проблемами нейминга и прививание каких-то хороших практик следует делать на начальных этапах пока кода не слишком много. Студенту будет проще в финале. Тут, конечно, много "но" и сильно зависит от возможности студента эти практики перенимать.

Встроенные методы массивов просят отдельного критерия. И я бы туда добавил пример как не надо - когда мы берем forEach и делаем push вместо map.
А "используются по назначению" расширить бы на все методы отдельным критерием, как пример replace с колбэком для перебора символов строки.

Идея добавить отдельный критерий про подобные методы мне нравится. Возможно немного оверхед для level 1, но хорошая мотивация побольше поработать чтобы получить 100%.

Д25 про Длинные функции можно перенести в ESLint с max-lines-per-function, и очень хочется принудительно ограничить длину строки))

Поддерживаю всеми "за". Постоянно приходится объяснять студентам, что не рекомендуется делать длинных функций и длинных строк.

Вообще как вы смотрите на расширение правил eslint конфига в сторону автоматических проверок доп критериев? Наставникам проще будет, студенты вроде когда с ограничением сталкиваются неизбежно начинают разбираться что это и зачем. Они конечно допы, вроде как необязательны, но тот же consistent-return у нас включен.

Положительно смотрим и количество автоматических проверок будет расширяться однозначно. Критерии также пересмотру подвергаются. Думаю, что-то увидим уже на грядущем обновленном level 2.

[balesniy]

Если расширить формулировку критерия

по функциям формулировка отличная, она включает в себя "соответствовать действию, которое выполняет функция", вот что то бы подобное еще для переменных в Б4 добавить.

Идея добавить отдельный критерий про подобные методы мне нравится.

у нас сейчас это описано в "подвале" Д8 после "API встроенных функций", если выносить их в базовые как предлагает @Spearance, то методы массивов как раз останутся в допах.

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

я могу что то сделать практически для реализации?) чуть больше года как завел ишью в eslint-config-htmlacademy по поводу длины сроки. например составить список соответствия критериев академии и правил eslint для обсуждения. Сам пользуюсь инспектором WebStorm на проверках, можем согласовать "официальный" профиль?

[AntonovIgor]

у нас сейчас это описано в "подвале" Д8 после "API встроенных функций", если выносить их в базовые как предлагает @Spearance, то методы массивов как раз останутся в допах.

Я понял тебя. Я сейчас пробежался по критериям и сам вспомнил, что периодически подобные штуки указывал как раз в этом критерии. Поэтому можно тут их и указывать, предварительно добавив примеров в описание. Наверное, так.

я могу что то сделать практически для реализации?) чуть больше года как завел ишью в eslint-config-htmlacademy по поводу длины сроки. например составить список соответствия критериев академии и правил eslint для обсуждения. Сам пользуюсь инспектором WebStorm на проверках, можем согласовать "официальный" профиль?

Спасибо! Если уже есть issue, то ok. Обсудим с командой авторов этот вопрос.

[sashasushko]

Забрали к себе. Закрываю