В тысячный раз о code review
Почему в тысячный?
Потому что я вбила здесь в поиске «code review» и обнаружила 50 страниц по 20 результатов на каждой.
Штуки три с высоким рейтингом прочитала. Но всё по понятным причинам не осилила.
Вероятно, не все мысли в этом посте будут новыми. Но некоторых из мыслей я не нашла в тех трёх рейтинговых постах. Поэтому считаю, что этому посту быть.
Итак. Есть много способов для повышения качества кода, создаваемого командой: тестирование, статический анализ, экстремальное программирование,… Сегодня расскажу о code review.
Для тех, кто не в курсе, code review — это процесс просмотра кода, сделанного одним разработчиком, другим разработчиком с последующей выдачей комментариев. В идеале, это повышает качество кода.
Во мне процесс code review вызывает смешанные чувства: с одной стороны, это безусловное благо. Правильно настроенный процесс повышает культуру разработки кода, позволяет старшим сотрудникам ненавязчиво делиться опытом с новичками, улучшает качество инженерных решений и т.д. С другой стороны, если ты та самая старшая разработчица, грамотно и вдумчиво проводящая ревью, то каждый первый младший разработчик в твоей команде стремится заполучить твое мнение по поводу своего кода. И вот ты проводишь до трёх часов в день просматривая чужой код вместо того, чтоб писать свой.
Это цена. Не все команды согласны её платить в погоне за качеством. Мне везло работать в тех, что согласны.
Итак, поехали. Как проводить code review, чтобы извлечь из процесса максимальную пользу?
Вежливо. Даже если вам кажется, что коллега написал это код в пьяном угаре не иначе, нужно выдавать свои комментарии в максимально корректной форме. Все ошибаются. Это не повод их стыдить, высмеивать и прочее. Цель всего — улучшить качество вашего совместного продукта. А блеснуть своим белым пальто можно и в другом месте, если хочется. Пишите комментарии так, как вы бы хотели, чтоб их писали вам.
В одиночестве. Лучше, если сначала вы посмотрите чужой код одни, в спокойной обстановке. Свежим взглядом. Потом уже можно обсудить его с автором.
Задавать вопросы в случае недопониманий. Тут всё просто. Нужно стремиться понять чужую мысль на 100%. Как вы знаете, если когда-нибудь читали чужой код, это не всегда бывает просто. Если что-то непонятно — спросите автора, можно по телефону, если так быстрее.
Использовать комментарии. В коде имею ввиду. Хорошо откомментированный код снижает количество созвонов, требующихся в предыдущем пункте Помните об этом. Экономьте чужое время.
Соблюдать определённые ограничения. Эксперты советуют просматривать за раз не более 500 строчек кода, а также ограничивать длительность ревью шестьюдесятью минутами. Тут бы ссылку на источник, но я не помню, где видела это правило. Но оно правда дельное. Пользуйтесь.
Использовать чек-лист. Чтобы повысить эффективность себя как ревьюэра, хорошо бы завести список того, на что надо обратить внимание. Мои три общеупотребимые вещи для проверки: дубликации кода; грамотное использование RAII (это ещё что такое? Кто не знает — объясню как-нибудь ещё); грамотное именование сущностей. Остальное специфично для языка и для проекта.
Принимать чужое мнение. Обычно в программировании нет единственно правильного способа сделать что-то. И если автор сделал что-то не так, как бы сделали вы и у вас есть смутное чувство дискомфорта по этому поводу. Но грамотно объяснить, чем способ автора хуже, чем ваш вы не можете. Встаньте на сторону автора. Вот правда. Никому не нужна эта священная война с непонятной выгодой. От разнообразия решений ваш проект только выиграет, возможно
Как НЕ НАДО проводить code review?
Юмор за 300. Как мы помним, вежливось очень ценна для грамотного code review. Я понимаю, что бывает присылают на ревью такое, что сложно не взоржать, и что мы все тут дофига юмористы. Но правда, лучше поржите с подружками после работы. Если у вас есть подружки-программистки не из вашей команды, расскажите им эту фееричную шутку — они оценят. Code review достаточно личная штука и шутки над кодом могут быть восприняты как личное оскорбление. Не надо так.
Пытаться делать работу по отлову ошибок. Это не то, на чём нужно концентрироваться. Для отлова ошибок существует тестирование, валидация в конце концов. Оставьте эту работу тестам. А при ревью лучше сконцентрироваться на том хорошо ли код спроектирован. SOLID принципы, идиомы объектно-ориентированного программирования. Вот это всё. На этом концентрируйтесь. Хорошо ли такой код будет расширять и поддерживать в дальнейшем? Эти вопросы должны вас волновать в первую очередь, на мой взгляд.
Проверять соответствие стилю (в смысле coding style/coding guidelines). Не нужно. Все проверки правильного количества пробелов, длинны строк, наличия табов и т.д. оставьте роботам. Т.е. просто введите в ваши процессы автомат по выравниванию стиля. Indent, clang-format и т.д. вам в помощь.
Если нужно что-то индивидуальное, наличие правильной «шапки» в файлах проверять или какое-то особенное именование сущностей — скрипт напишите. Всё, что может быть автоматизировано недорогой ценой должно быть автоматизировано. Программисты мы или кто в конце концов? Это цель нашей работы — упрощать людям жизнь. Ну и себе можно жизнь упростить по дороге
Всем хороших code review.
А с меня хватит на сегодня, пожалуй.
