Горский Илья, фронтенд-разработчик в команде Talantix.
Домашки принимаются до 20-го декабря включительно в Mattermost в личке.
Если что-то непонятно или не получается сделать — приходите в Mattermost, обсудим, решим, посмотрим примеры.
- Сделайте форк репозитория https://github.com/ipetropolsky/js-part-0
- Склонируйте его к себе на машину, создайте ветку от master.
- Поправьте функцию
test()так, чтобы она работала с массивами примитивов. - Запускайте код в консоли браузера (это неудобно) или любым другим способом.
- Добавьте отсутствующий код так, чтобы проходили все тесты.
- Проверьте, что нет ошибок и ворнингов:
yarn eslint . - Сделайте пулл-реквест в своём репозитории, поставьте меня ревьювером и скиньте линк на него.
Можно пользоваться чем угодно, главное не списывать у коллег. А вот обсуждать варианты решений — пожалуйста, это всегда полезно.
Переименовывать функции и править комменты можно, но смотрите на дифф. Всё стереть и переписать на jest и lodash прикольно, но усложнит ревью. И в реальной жизни у вас обычно нет возможности просто переписать всё как вам захочется :)
- Установите NodeJs, если его нет.
- Установите yarn, если его нет.
- Установите зависимости для линтинга (запустите
yarnилиnpm installв папке проекта). - Включите в своём редакторе ESLint, отключите JSHint и другие линтеры.
- Запускайте код в терминале:
node index.js(это удобно). - Добавьте недостающих тестов на своё усмотрение (отдельным коммитом).
Некоторые правила eslint, которые мы обычно используем, отключены для удобства разработки.
Например, no-unused-vars, no-console, no-new-wrappers.
# getType
[OK] Boolean
[OK] Number
[OK] String
[OK] Array
[OK] Object
[OK] Function
[OK] Undefined
[OK] Null
# allItemsHaveTheSameType
[OK] Values with the same type
[OK] Values with various types
[OK] Values like a number
[OK] Values like an object
# getTypesOfItems VS getRealTypesOfItems
[OK] Check basic types
[OK] Check real types
# everyItemHasAUniqueRealType
[OK] All value types in the array are unique
[OK] Two values have the same type
[OK] There are no repeated types in knownTypes
# countRealTypes
[OK] Count unique types of array items
[OK] Counted unique types are sorted
Ваш коллега подготовил ветку с изменениями, разбил их на коммиты по смыслу (если много кода в разных местах), описал, какую задачу он решает и почему так, приложил картинки места, где это происходит (если это не очевидно по коду).
Потом он приходит к вам и говорит:
Привет! Заревьюй, пожалуйста: ipetropolsky#4
Вы как ревьювер:
- Внимательно читаете описание PR.
- Заходите в
Files changed, пишете конструктивные комменты или вопросы любой степени глупости (вам потом работать с этим кодом, всё должно быть предельно ясно). - Жмёте
Review changesсправа сверху, выбираете там один из вариантов по своим внутренним ощущениям.Approveможет быть и с минорными комментами на усмотрение автора кода.Comment— по сути приглашение к обсуждению: нормально, но можно лучше. Но можно и так оставить.Request changesесли считаете, что так выпускать нельзя и нужно что-то поправить.
- По желанию оставляете в том же окошке какой-то общий коммент, описывающий весь PR, например:
Что-то дофига логики на фронте, было бы здорово прислать всё с бэка.
- Даёте коллеге понять, что поревьюили, чтобы он не терял времени и двинул задачу дальше или обсудил с вами спорные моменты.
- При обсуждении обе стороны пытаются найти простое и понятное всем решение. Автор кода понимает, что вопросы и предложения появляются неспроста, возможно его код несовершенен. Ревьювер не настаивает на своих вариантах, если это не критично. А где критично, объясняет, почему.
- Результаты ревью можно обсудить в чате, чтобы ускорить процесс, но спорные моменты лучше потом всё равно зафиксировать в PR на Гитхабе, чтобы другим людям было понятно, что вопрос исчерпан и решение вот такое.
- Если нужны исправления, автор кода пушит их отдельными коммитами, чтобы было видно, что изменилось.
После ревью можно схлопнуть их. См.
git commit --fixup $HASHиgit rebase -i.