.NET Разработчик(@NetDeveloperDiary). День 1092. #CodeReview 10 Советов по Написанию Эффективных Обзоров Кода. Начало Существует несколько

День 1092. #CodeReview 10 Советов по Написанию Эффективных Обзоров Кода. Начало Существует несколько хороших практик, которые рецензент может использовать, чтобы сделать процесс рецензирования менее скучным и более ясным. Это выигрыш для всех, потому что: - автор будет более четко понимать ваши отзывы, что приведёт к меньшему количеству итераций обзоров кода; - вы будете давать автору советы и замечания, которые повлияют на его подход к кодовой базе в целом, чтобы в следующий раз было меньше «ошибок». Вот несколько советов и практических правил относительно подхода к процессу рецензии. 1. Всегда сообщайте «почему» Рассмотрим некоторые типичные комментарии из обзора: - «неправильное имя функции», - «этого не должно быть здесь», - «думаю, это может сломаться». По этим комментариям автор кода может только предположить, что не так с его кодом. Но может прийти к неправильному выводу о том, почему он не верен, и сделать неправильное исправление. Это приведёт к дополнительной итерации обзора. Вот пример хорошего комментария: «Это имя функции не идеально; оно должно начинаться с глагола действия, и в этом случае иметь указание аргумента, типа '...ByUserId'. Подробнее см. документацию по стилю кода.» Да, вы написали кучу слов, зато ясно объяснили автору, что не так, и как следует поступать в будущем. 2. Будьте тщательны Автором кода может быть самый высокопоставленный человек в вашей команде, знающий все тонкости кодовой базы, или новичок, который отправляет свой первый код на обзор. Это не должно влиять на качество или тщательность вашей проверки, и вы не должны давать старшему сотруднику поблажки только потому, что доверяете его работе. Обзоры кода — это не только обеспечение качества и структуры кода, но и поиск граничных случаев или ошибок, которые автор мог не заметить, либо даже просто случайных опечаток. Признайтесь, это случается с лучшими из нас. Выявление ошибки до того, как она будет отправлена в производственный код, всегда более эффективно, чем обнаружение её в рабочем коде, создание багрепорта, поиск причины, исправление проблемы и отправка кода на повторную проверку. 3. Не выдавайте конечный результат Как рецензент изменений кода, вы не должны исправлять его или придумывать решение, когда обнаружите проблему. Да, вы можете помочь или предложить свою идею, но это не значит давать полное решение проблемы. Следующий комментарий мало чему научит автора: «Этот метод не совсем подходит, он должен быть примерно таким:

<кусок кода>

» Скорее всего, автор скопирует и вставит его себе, не задумываясь. И в дальнейшем не будет сильно беспокоиться о качестве своего кода, если будет знать, что вы за него всё исправите. Правильно в этом случае было бы описать, как должен выглядеть метод, объяснить, почему код не сработает, и как бы вы подошли к решению проблемы. Иногда допустим псевдокод. 4. Не откладывайте обзор Очень важно не блокировать работу друг друга. Переключение контекста — непростая задача для разработчика. И в ожидании обзора кода по одной из своих задач автору придётся переключиться на другую, и переключаться туда и обратно, по мере получения комментариев и ответа на них. Это в любом случае произойдет, даже если проверка пройдёт очень быстро. Однако, чем дольше затянется обзор, тем больше таких переключений будет происходить. Кроме того, вы можете и фактически блокировать чью-то работу. Т.е. люди не смогут продолжать работу, пока эта функция не будет завершена и изменения кода не будут объединены. Всё это неэффективно и раздражает обе стороны. Чтобы убедиться, что такого не произойдёт, всегда полезно отдавать приоритет проверкам кода в своем расписании. Конечно, у вас могут быть более срочные задачи, но вы обязаны найти правильный баланс между собственной работой и обзорами. Окончание следует… Источник: betterprogramming.pub/10-tips…25aa22c5