Недавно у меня был очень содержательный разговор с одним из старших инженеров нашей команды о том, что комментарии по обзору кода иногда бесполезны или неправильно понимаются относительно молодыми программистами и как мы можем улучшить. Очевидно, это очень широкая тема, и я понял, что о процессе предоставления и получения комментариев при проверке кода не так много говорят, и у каждого есть свое понимание и интерпретация.

Когда кусок кода выставляется на рассмотрение, предполагается, что автор протестировал его с помощью модульных тестов, интеграционных тестов, других автоматических тестов, если это необходимо, или вручную, в худшем случае. Короче работает! Теперь задача рецензента - выяснить, есть ли какие-либо потенциальные ошибки, соответствует ли он требованиям и выполняет ли то, что ему нужно, и есть ли какие-либо пропущенные сценарии, о которых автор на самом деле не подумал. В некотором смысле, рецензенты кода также обязаны убедиться, что проверяемый ими код не ухудшит качество всей кодовой базы.

В этом посте я постараюсь перечислить несколько вещей о том, как давать и получать комментарии при проверке кода, которые помогут инженерам стать лучше при проверке кода и, в конце концов, стать победителями.

1. Сделайте рецензирование кода частью процесса

Работая в команде из нескольких человек, ему требуется немного координации и посвященное время, чтобы посмотреть на код других людей и проверить его. Легко упустить возможность просмотреть чей-то код, потому что вы заняты своей задачей. Пропущенная проверка кода так же хороша, как и упущенная возможность узнать что-то новое. Вот почему проверка кода должна быть явной частью процесса.

Когда вы следуете гибким процессам разработки программных продуктов, включение проверки кода в процесс означает так же просто, как наличие столбца «На рассмотрении» в вашей пользовательской раскадровке. Тот, кто работает над историей, откроет запрос на вытягивание и переместит задачу в столбец «На рассмотрении», когда он / она закончит с задачей. В следующий раз, когда вы встретитесь для стендапа, все будут знать, что вы выполнили задачу, и им нужно просмотреть код. Так просто!

В личном плане я обычно выделяю не менее 30 минут выделенного времени каждый день для проверки кода. Это помогает обеим сторонам - когда я просматриваю код, я пытаюсь понять, как определенная функция реализована автором, и извлекать уроки из этого. С другой стороны, автору выгодно, если есть что исправить или улучшить. В противном случае история будет перемещена на следующую дорожку на доске рассказов, как только будет завершена проверка и автор будет готов выбрать следующее задание.

2. При необходимости поговорите с автором напрямую.

Проверки кода обычно выполняются рецензентами изолированно. Однако, когда дело доходит до сложных функций, всегда рекомендуется проверять код в группе или напрямую с автором. Это не только исключает риск неправильного понимания подхода автора, но и помогает ускорить процесс.

Не имеет отношения к обзорам кода, но на самом деле это очень хороший подход к объединению программ или групповых программ для таких сложных задач, чтобы вы выполняли одновременный обзор во время написания кода. Кроме того, в конечном итоге все знают о решениях, принимаемых при написании кода, и устраняется необходимость в формальных проверках кода, что в конечном итоге приводит к быстрому циклу разработки.

Почему прямое общение с автором помогает? Представьте запросы на вытягивание, содержащие код, который значительно отличается от фактических требований, или вы думаете, что принятый подход слишком сложен для задачи и может быть упрощен. Вы оставляете несколько комментариев, автор отвечает, и игра в пинг-понг продолжается некоторое время. К тому времени, как вы это понимаете, уже есть длинная цепочка из 50+ комментариев по PR и без заключения. Это признак того, что разговор должен происходить лично, а не на пиаре.

3. Будьте объективны, кратки и точны.

Когда вы комментируете какой-то код, придерживайтесь сути! Важно, чтобы автор точно знал, что вы имеете в виду. Если вы хотите предложить некоторые улучшения, опишите их объективно, а не оставляйте комментарий открытым. Например, намерения рецензента не ясны из следующих комментариев.

Более четкой альтернативой этому будет что-то вроде ниже -

Воспользуйтесь стандартами кодирования, терминологией и т. Д., Чтобы уменьшить субъективность в ваших комментариях. Даже если автор не знает об этом, поиск и чтение о них, безусловно, поможет ему / ей понять, что имеет в виду рецензент.

4. Будьте вежливы

Очень легко, что автор неправильно поймет ваши комментарии, и, следовательно, вежливость и уважительное отношение являются наиболее важной частью процесса проверки кода. Если вы как рецензент видите что-то не так, вы можете быть очень прямолинейным и прямо прокомментировать код, как показано ниже:

Или вы можете проявить уважение и предложить альтернативный подход таким образом, чтобы он не звучал так, как будто вы диктуете решение автору, и не звучал грубо. Вежливость - ключ к успеху.

Если код действительно находится в плохом состоянии, оставление кучи комментариев к таким PR может поставить автора в неловкое положение, и, следовательно, личная беседа с автором может быть полезной, как упоминалось в предыдущем разделе.

5. Комплимент.

Вы можете учиться, читая книги, просматривая видео по программированию, но знания, которые вы получаете на работе, абсолютно бесценны. Поскольку вы участвуете в решении реальной проблемы, вы можете легко найти решение и вспомнить его в следующий раз, когда вам придется решить ту же проблему.

При этом проверка кода не всегда сводится к поиску ошибок или проблем в чужом коде. Если вы видите обзор кода с более приятным подходом к решению данной проблемы, вы должны оценить усилия автора. Это не только поднимает моральный дух автора, но и повышает общую продуктивность команды.

👍 или простая улыбка 🙂 могут творить чудеса. Некоторые примеры могут быть -

6. Будьте полезны

Я не могу больше настаивать на том, что обзоры кода могут быть лучшим источником для изучения. Как рецензент, вы можете быть полезны своим коллегам, делясь своими знаниями в виде комментариев по обзору кода.

Как говорится, практика делает мужчину идеальным. Инженер-программист с годами, потраченными на кодирование и создание программного обеспечения, накопил обширный опыт, и если опыт решения проблем, шаблонов проектирования, небольших советов и приемов, методов чистого кода и т. Д. Делится через комментарии обзора кода, я уверен, что большая часть команды участники будут вам благодарны.

Надеюсь, это поможет улучшить общее впечатление от проверки кода. Не забывайте делиться и аплодировать! 🙂