Проверка задания ментором

Студент выполняет задание в приватном репозитории.
Студент создает и оформляет Pull Request до дедлайна.
- Правила оформления PR указаны ниже
- Штрафы за нарушения дедлайна указаны ниже
До выставления финальной оценки ментором, студент может продолжать реализовывать фичи
Ментор проверяет PR, оставляет свои замечания и рекомендации по качеству кода (copy-paste, magic numbers, project structure, etc.) и реализованной функциональности. Указывает предварительную оценку в комментарии.
- Оценка выставляется ментором на основании критериев оценки указанных для каждого задания
- При выставлении оценки учитывается весь реализованный функционал. Например, студент выполнил минимальные требования не на 100 процентов, но выполнил часть дополнительных - все требования должны учитываться
- Ментор может выставить предварительную оценку авансом, с учетом того, что студент исправит все замечания ментора
Студент в течении 5 дней исправляет замечания ментора.
- Если комментарии ментора к PR предполагают ответ студента - студент пишет ответ
- Если студент вкоммитал правки, он должен оставить комментарий о том, что именно было вкоммитанно/исправлено
По результатам исправления ментор выставляет окончательную оценку в Score (RS APP > Submit-review) .
- Ментор сам решает снимать баллы или нет за функциональность реализованную студентом после дедлайна.
- Если студент не исправил замечания ментора по качеству кода, ментор может дополнительно снизить оценку. Размер штрафа на усмотрение ментора, максимум -50 баллов.

Требования к Pull Request (PR)

Pull Request - это место для обсуждения кода. Он не должен выглядеть как монолог студента или ментора. Будьте культурными, уважайте время и работу друг друга.

Описание Pull Request должно содержать следующую информацию:

Ссылка на задание.
Скриншот результата выполнения задания (страница созданного приложения или сайта). Скриншот добавляем в Pull Request в виде изображения. Для добавления в Pull Request изображения, его можно просто перетянуть с компьютера.
Ссылка на задеплоенную версию вашего приложения или сайта. Для деплоя можно использовать:
- при наличии приватного репозитория школы - gh-pages
- при отсутствии приватного репозитория школы или при невозможности разместить приложение на gh-pages приватного репозитория школы, приложение можно разместить на netlify.com, либо на другом подобном хостинге.
- для демоверсий, размещённых на netlify, название сайта даётся по схеме: имя гитхаб аккаунта - название таска.
Дата сдачи / дата дедлайна.
Ваша самопроверка с предварительной оценкой.

Пример оформления

1. Task: https://github.com/rolling-scopes-school/tasks/blob/master/tasks/fancy-weather.md
2. Screenshot:
   ![](https://docs.rs.school/images/fancy-weather.png)
3. Deploy: https://chakapega-fancy-weather.netlify.com/
4. Done 28.05.2020 / deadline 31.05.2020
5. Score: 220 / 300
- Вёрстка, дизайн, UI (15/30)
  - [x] минимальная ширина страницы, при которой она отображается корректно – 320 рх (10)
  - [±] внешний вид приложения внешне соответствует макету или является его улучшенной версией (5/10)   
  - [ ] приложение корректно отображается для любого выбранного языка (0)
- В блоке "Погода за сегодня" отображаются следующие данные (15/20)
  - [x] данные о погоде и местоположении пользователя (10)
  - [±] часы, обновляющие время каждую секунду (5/10) 
 ...

Pull Request не должен содержать:

Закомментированного кода
Лишних файлов, автосгенерированного кода, node_modules и т.д.

Пример проверки студенческого PR ментором

Проверку пулл реквеста можно начать с проверки корректности оформления PR, именования коммитов и достаточного их количества.

Далее можно склонировать репозиторий, установить зависимости и проверить собирается ли проект. Если в требованиях было использования линтера или тестов проверить наличие прописанного скрипта для запуска (lint, test), возникают ли ошибки после запуска. Так же стоит обратить внимание есть ли в коде места, где выключены правила линта и попытаться выяснить для чего это было сделано и можно было ли этого избежать. Стоит проверить общую функциональность приложения, отсутствуют ли ошибки в консоли, корректно ли отрабатывают запросы и т.д. На этом этапе можно обратить внимание на возможные UI/UX проблемы:

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

Далее code review. Возможные моменты, где можно улучшить качество кода: Общие принципы

DRY - если есть повторяющиеся куски кода, лучше выносить их в отдельный класс/функцию
KISS - пытаться сохранить простую и понятную структуру
комментарии стоит оставлять для объяснения задачи кода, а не для его описания

Bad

# method to find min value
function findMinValue() {...}

не использован форматтер кода, они помогают привести код к одному стилю для всех членов команды (e.g. prettier)
лучше для именования переменных/классов/функций не использовать сокращения, это улучшит понимание и читабельность кода

HTML

отсутствие атрибута alt для тeга img, так же рекомендуется проставлять высоту и ширину, это полезно когда картинка по какой-то причине не подгрузится
отсутствие или недостаточная семантика
избыточные блоки

<div class="container">
  <div class="wrapper">
    <ul>
      ...
    </ul>
  </div>
</div>

для html использовать имена классов в kebab-case

<!-- BAD -->
<div class="containerWrapper"></div>

<!-- GOOD -->
<div class="container-wrapper"></div>

если в html нужно сделать какой-то заголовок в upper case лучше это делать стилем
использование в HTML inline стилей или js-кода, например, в виде функции onclick, также является ошибкой

CSS

динамические стили стараться применять классами, а не js
стараться писать стили с небольшой степенью вложенности (не больше 2х) - это упрощает сопровождение и переопределение стиля при необходимости
предпочтительнее использовать одни единицы измерения (или px или rem или em) это позволит проще вносить изменения(при использовании препроцессоров можно написать функцию, которая будет переводить пиксели в рем)

использовать event delegation, если его можно использовать
для блоков if else for использовать скобки
magic numbers and magic strings - стараться выносить их в отдельные константы
использовать объекты enums

const KEY_CODES = {
	Space: 32,
	Enter: 13,
	...
}

if (key === KEY_CODES.Enter) {
  ...
}

размер файлов (большие файлы трудно читать и поддерживать, если файл больше 200 - 400 строк, то следует задуматься о разделении)
следить за степенью вложенности условных блоков, блоки со степенью вложенности 3 и более трудно читать и воспринимать, возможно их можно вынести в отдельную функцию
стараться использовать чистые функции (они лучше тестируются)
использовать named arguments если число аргументов 3 и более, это позволяет не следить за порядком и при чтении кода более понятно что передается в функцию

function insertElement({ parent, tag, class, value }){...}

insertElement({ parent: parentElement, tag: 'p', class: 'class', value: 'Some value' })

Дедлайны для студентов

Дедлайны всех тасков указаны в расписании курса.
Если студент не успел сдать задание вовремя, ментор по своему желанию может применить следующие штрафы:
- -10 баллов к оценке при опоздании до 3 дней включительно
- -30% процентов к оценке при опоздании до 7 дней включительно
- -70% процентов к оценке при опоздании более чем на неделю
- по усмотрению ментора, при наличии уважительной причины (больница, армейские сборы и т.д.)
- При применении штрафных коэффициентов, округление происходит в пользу студента

Дедлайны для менторов

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