Домашнее задание по JS, первая лекция

Кому и когда сдавать

Горский Илья, фронтенд-разработчик в команде Talantix.

Домашки принимаются до 20-го декабря включительно в Mattermost в личке.

Если что-то непонятно или не получается сделать — приходите в Mattermost, обсудим, решим, посмотрим примеры.

Задание

1. Сделайте форк репозитория https://github.com/ipetropolsky/js-part-0
2. Склонируйте его к себе на машину, создайте ветку от master.
3. Поправьте функцию test() так, чтобы она работала с массивами примитивов.
4. Запускайте код в консоли браузера (это неудобно) или любым другим способом.
5. Добавьте отсутствующий код так, чтобы проходили все тесты.
6. Проверьте, что нет ошибок и ворнингов: yarn eslint .
7. Сделайте пулл-реквест в своём репозитории, поставьте меня ревьювером и скиньте линк на него.

Важно

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

Переименовывать функции и править комменты можно, но смотрите на дифф. Всё стереть и переписать на jest и lodash прикольно, но усложнит ревью. И в реальной жизни у вас обычно нет возможности просто переписать всё как вам захочется :)

Опционально

• Установите NodeJs, если его нет.
• Установите yarn, если его нет.
• Установите зависимости для линтинга (запустите yarn или npm install в папке проекта).
• Включите в своём редакторе ESLint, отключите JSHint и другие линтеры.
• Запускайте код в терминале: node index.js (это удобно).
• Добавьте недостающих тестов на своё усмотрение (отдельным коммитом).

Некоторые правила eslint, которые мы обычно используем, отключены для удобства разработки. Например, no-unused-vars, no-console, no-new-wrappers.

См. также:

• Install Node.js on Windows Subsystem for Linux (WSL2)

Что должно получиться

# 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.