Несколько правил хорошего тона код-ревью для разработчиков. Код-ревью — важный этап разработки, но он может создать много неудобств при неправильной организации. Мы собрали несколько принципов дружелюбного и эффективного ревью кода.
Автоматическая проверка ошибок
Если вы еще не внедрили автоматизированные системы проверки простых ошибок а-ля «пропуск пробела», то сделайте это немедленно. Инструменты гораздо зорче глаза программиста улавливают мелочи, которые могут быть пропущены из-за пресловутого человеческого фактора.
Используйте любую подходящую систему или программу-линтер: Travis, CircleCI, pyflakes для Python и JSLint для JavaScript, а также ClangFormat (для C/C++) или gofmt для Go и другие.
Не уделяйте слишком много внимания стилю
Да, единообразие кода важно, кто же с этим спорит? Но дело в том, что обсуждать его во время ревью — повод для бессмысленных прений и лишние минуты, которые всегда на вес золота.
Заведите гайд по стилю: этим вы решите раз и навсегда все возможные разногласия. Постепенно дополняйте руководство и поддерживайте его в актуальном состоянии. На соответствие принятому стандарту код тоже можно проверять автоматически.
Отводите на ревью достаточно времени
Просматривать код параллельно другим делам неконструктивно. Во-первых, это проявление небрежности и невежливости, во-вторых, запоротая задача. Когда вам прислали код на обзор, начать просматривать его нужно немедленно, но не торопясь, а внимательно и с погружением в задачу. Ваш коллега ждет отзыва и его работа приостановлена, пока вы не прокомментируете и не одобрите список изменений.
Вам также будет интересно:
• Оскорбление чувств пользователей: как быть политкорректным в IT
• Как правильно изучать программирование: метод Франклина
• Языки меняются, платформы остаются: Дмитрий Щипачев, Finch — о карьере и жизненном пути разработчика
Помогайте, а не осуждайте
Цель код-ревью — не только отлов багов, но и обучение, обмен знаниями и опытом. Поэтому старайтесь сделать этот процесс максимально полезным для разработчиков и не вызывающим дискомфорт из-за критики. Идеальный результат любого код-ревью — искренняя благодарность коллеги.
Человек не должен чувствовать себя виноватым, что не знает чего-то. Поэтому задумывайтесь над корректностью своих формулировок, даже если подробное объяснение с примером займет времени больше, чем «Это должно быть так, и точка». Сарказм, шутки и мемы уместны в небольших командах разработки, где все давно друг друга знают и находятся примерно на одном профессиональном уровне.
Объединяйте типичные ошибки
Если человек допустил недочет в одной строке, то, вероятно, он повторится по всему фрагменту кода. С одной стороны, удобно отметить все ошибки — когда автор внесет исправление, комментарий исчезнет. С другой стороны, это слегка угнетает и создает тот самый дискомфорт. Объедините общие моменты одним подробным комментарием — это будет гораздо продуктивнее для всех.
Подкрепляйте замечания примерами
Заявление без цитаты из документации, кода или формальных требований выглядят голословно. Вашим коллегам нужно понимать, почему предлагаемые изменения должны быть внесены, а личное мнение не имеет цены без аргументированного подкрепления.
Поэтому писать «В этом компоненте не должно быть состояний» неверно. Вместо этого расширьте контекст вашего совета и дайте пример:
«Его можно сделать функциональным компонентом без состояний, так как он не имеет методов или состояний жизненного цикла. Это улучшит производительность и читабельность. /Вот пример/ в документации».
Курс «Профессия веб-разработчик»
Рекомендуем курс обучения веб-разработке, где ваш код будут разбирать в подробностях опытные наставники, умеющие делать это по-настоящему профессионально. В ходе программы вы освоите HTML, CSS, JavaScript, пройдете все этапы работы над сайтом и приобретете множество полезных навыков.
Программа курса