Что проверять на code review

review.md

• Ревью - задача с наивысшим приоритетом. Желательно приступать к ревью как можно скорее. Это поможет избежать массового мержа задач в конце спринта и не будет тратить время коллег, особенно если задачи взаимозависимы. Начинаем ревью задачи при первом стабильном билде.
• Прежде всего нужно проверить соответствие указанного номера задачи, репозитория и версии указанным в Jira, а в ходе ревью обратить внимание, соответствуют ли внесенные изменения поставленной задаче.
• Названия коммитов и PR пишутся с большой буквы, они должны содержать номер задачи, описывать внесенные изменения и быть обезличенными. Плохой пример: “сделал правки”, хороший пример: “UFSUI-1111 Исправлена работа скролла в Select при открытии вверх”.
• На ревью обязательно нужно как посмотреть код, так и проверить корректность работы компонента с внесенными изменениями. Код стоит проверять досконально в каждом файле. При проверке работы нужно попытаться воспроизвести все возможные кейсы использования компонента. Не стоит пренебрегать одним из шагов, даже если это мелкая правка стиля.
• Изменения должны соответствовать соглашению по CodeStyle. Единообразие форматирования важно для хорошей читаемости кода и избежания лишних ошибок, поэтому желательно при каждом изменении прогонять tslint. Не нужно забивать на замечания по отступам, названиям переменных, стилю кода, соблюдению правил русского языка и DRY.
• Ревью - не критика, а совместные усилия, чтобы сделать хороший продукт. Поэтому всегда желательно указывать на конкретную ошибку, чтобы человек понял её, и предлагать варианты решения сложных ситуаций. Не спорьте с автором долго, для прихода к общему мнению проще спросить мнения у дизайнера или команды.
• Желательно проводить ревью по всем изменениям сразу, чтобы автор кода сразу понимал, сколько правок его ждет.
• Все внешнее API должно быть задокументировано с помощью PropsDoc. Документация должна содержать подробные примеры использования компонента и информацию о внесенных изменениях, если они касаются внешнего API. При этом необходимо проверить, чтобы в документации не показывались скрытые пропсы, и показывались новые.
• Правки по code style и тексту документации допустимы в пределах разумного и исключительно в файлах, по которым сделаны изменения в соответствии с задачей. В остальных случаях “лишние” правки, не относящиеся к задаче, нужно убирать, так как это затрудняет ревью и провоцирует возникновение мерж-конфликтов.
• Желательно везде использовать собственные вспомогательные функции вместо сторонних библиотек вроде lodash. При использовании одной вспомогательной функции в нескольких местах она должна быть вынесена в папку utils.
• Необходимо помнить про взаимозависимость некоторых компонентов и также проверять их работу.
• При удалении какого-либо функционала необходимо проверить, что удалено всё, связанное с этим функционалом. Например, специфичные функции из utils, используемые только там, лишние стили, лишние глобальные классы, упоминания и ссылки в документации.
• При изменении списка npm-пакетов необходимо удостовериться, что внесенные изменения не повлияют на работу компонентов, зависящие от этих пакетов, а также что версии всех пакетов жестко зафиксированы.
• Если что-то в коде вам не понятно без подробного объяснения автора - просите написать комментарий, почему выбрано именно такое решение.
• На любое добавление функционала или его изменение должен быть написан/переписан тест. Тесты должны быть написаны таким образом, чтобы при отсутствии данного функционала они падали.
• Желательно наличие тестов на нестандартные случаи (например, передача null через props).
• Покрытие unit-тестами по Statements должно быть не меньше, чем до изменений. В идеале это 100%.
• Помимо покрытия, необходимо также проверять отсутствие новых предупреждений и ошибок в логах тестов.
• Необходимо проверить, что изменение будет корректно работать со всеми возможными состояниями компонента и сочетаниями пропсов.
• Проверить, что правки багов и добавление функционала по старой версии библиотеки также внесены в новую версию.