Обзоры кода
Просмотр запросов на исправление - распространенный вид вклада. Несмотря на то что непрерывная интеграция (CI) гарантирует, что код делает то, что должен делать, этого недостаточно. Существуют характеристики вклада, которые невозможно автоматизировать: дизайн, структура и архитектура кода, качество тестов или опечатки. В следующих разделах представлены различные аспекты процесса проверки кода.
Читаемость
Ясно ли код выражает свои намерения? Если вам приходится тратить кучу времени на то, чтобы понять, что делает код, значит, его реализация нуждается в улучшении. Предложите разбить код на более мелкие абстракции, которые легче понять. В качестве альтернативы и последнего средства они могут добавить комментарий, объясняющий причину такого решения. Спросите себя, сможете ли вы понять код в ближайшем будущем без какого-либо окружающего контекста, например, описания запроса.
Небольшие запросы на вытягивание
Большие запросы сложно просматривать, и в них легче упустить детали. Если запрос становится слишком большим и неуправляемым, предложите автору разбить его на части.
::: инфо ИСКЛЮЧЕНИЯ
Есть несколько сценариев, когда разделение запроса на вытягивание невозможно, например, когда изменения тесно связаны между собой и не могут быть разделены. В таких случаях автор должен предоставить четкое объяснение изменений и их обоснование.
:::
Последовательность
Важно, чтобы изменения согласовывались с остальной частью проекта. Несогласованность усложняет сопровождение, поэтому ее следует избегать. Если есть подход к выводу сообщений пользователю или сообщению об ошибках, следует придерживаться его. Если автор не согласен со стандартами проекта, предложите ему открыть тему, где мы сможем обсудить это подробнее.
Тесты
Тесты позволяют изменять код с уверенностью. Код в pull request'ах должен быть протестирован, и все тесты должны пройти. Хороший тест - это тест, который постоянно дает один и тот же результат и который легко понять и поддерживать. Большую часть времени рецензенты проводят в коде реализации, но тесты не менее важны, потому что они тоже являются кодом.
Разрывные изменения
Ломающиеся изменения - это плохой опыт для пользователей Tuist. Вкладчикам следует избегать внесения разрывных изменений, если это не является строго необходимым. Существует множество возможностей языка, которые мы можем использовать для развития интерфейса Tuist, не прибегая к ломающим изменениям. То, является ли изменение ломающим или нет, может быть неочевидным. Метод, позволяющий проверить, является ли изменение ломающим, - запуск Tuist с проектами фикстур в каталоге фикстур. Для этого нужно поставить себя на место пользователя и представить, как изменения повлияют на него.