Код-ревью и советы по повышению его качества: на что обратить внимание в первую очередь?
Привет, Хабр! Сегодня поговорим о код-ревью, т. е. проверке и оценке качества кода выполненной разработчиком задачи перед её релизом. У код-ревью несколько положительных моментов:
поиск багов и проблем кода, что значительно снижает вероятность проникновения этих багов в релиз
вовлечение членов команды в работу над различными задачами, к которым участники код-ревью часто не имеют прямого отношения. Это даёт лучшее понимание общего процесса работы
повышение качества кода и, наверное, общих стандартов разработки в компании, поскольку представители команды видят, что и как нужно делать для повышения качества работы
социальное взаимодействие в команде. Её представители дают друг другу обратную связь, постепенно повышая свой скил коммуникаций
Но на что обращать внимание в процессе код-ревью? Об этом сегодня и поговорим.
Чек-лист для код-ревью
Стоит отметить, что в коммерческой разработке код-ревью давно стал неотъемлемой частью работы. Он не должен быть чистой формальностью, поскольку в этом случае снижается значение всего процесса. Вот основные пункты для проведения код-ревью.
Соответствует ли реализация исходным условиям задачи?
Речь идёт о том, что код должен делать то, что нужно конечному пользователю программы или сервиса. Разработчик должен написать код, который удовлетворяет ожидания пользователя. Если это не так, код нужно доработать. Вот три важных вопроса:
Не упустил ли разработчик реализацию какой-либо фичи, важной для конечного юзера?
Возможно, есть частично/плохо реализованные фичи?
Можно ли добавить дополнительные возможности в будущем, если они понадобятся?
Читаемость кода
Есть несколько важных моментов относительно читаемости кода. Например:
Разбит ли весь код на понятные стороннему ревьюеру блоки?
Может ли ревьюер различить роль конкретных функций, методов и/или классов?
Не встречаются ли в коде непонятные выражения?
Есть ли необходимые для понимания кода комментарии? При этом комментарии должны объяснять, почему кодер сделал именно так, а не как он это сделал.
Соответствует ли код принятым в команде/компании гайдлайнам?
Одинаково ли хорошо отображается код на экране ноутбука и большом мониторе? Этот пункт необязателен, но часто желателен.
Зачастую дискуссии в команде возникают из-за непонимания назначения и принципа работы готового кода. Так что лучше писать/переписывать код так, чтобы вопросов о назначении определённого участка просто не было. Это не всегда возможно, но желательно.
Простота обслуживания кода
Об этом уже упоминалось выше — после того как софт или сервис готов, его в будущем, возможно, понадобится доработать, расширив возможности. И чем проще это можно будет сделать, тем меньше проблем получит разработчик или команда. Вот список вопросов, которые помогают понять, насколько просто будет сопровождать готовый код в будущем:
Не базируется ли код на какой-то устаревшей технологии/фреймворке?
Легко ли тестировать и отлаживать готовый код?
Можно ли быстро изменить значения данных?
Не чрезмерно ли усложнён код? Возможно, какие-то участки можно упростить?
Есть ли документация (употребимо для сложных проектов/задач)?
Информационная безопасность
В коде будущей программы/сервиса могут быть уязвимости, которые разработчик не заметил. Это крайне важно для коммерческой разработки, поскольку ИБ практически везде поставлена во главу угла. Вот список вопросов, которые стоит задать себе при ревью кода на подобные проблемы:
Проводится ли валидация текстового поля?
Надёжно ли хранится пользовательская информация?
Какого рода используется аутентификация и авторизация для обеспечения безопасности пользовательских данных?
Не используются ли в коде технологии с известными проблемами в безопасности?
Скорость работы и потребление ресурсов
Современное ПО часто ругают по поводу того, что оно потребляет большое количество ресурсов устройства. Банальный браузер может подвесить не слишком производительный ноутбук, не говоря уже о другом ПО. Поэтому разработчику стоит следить за тем, чтобы баланс производительности и потребления ресурсов его продукта был оптимальным.
Вот моменты, на которые стоит обратить внимание:
Не дублируется ли код?
Есть ли в коде конкатенации строк, предусмотрено ли ведение журнала или присвоение объектов, что может влиять на производительность готового продукта?
Нет ли в коде плохо оптимизированных участков, ненужных/множественных запросов API и т. п.?
Оптимальный размер кода для ревью и ещё парочка нюансов
В целом, всё зависит от разработчика/ревьюера/команды, но вообще чем меньше участок для ревью, тем лучше. Дело в том, что огромные участки кода обычно сложно оценивать. Они часто получают оценки вроде «всё ок», без подробных комментариев/обратной связи. Всё дело в том, что время ревьюера не резиновое, и если в небольшом участке кода он может оставить несколько комментариев, то в крупном фрагменте осилить сотню-другую комментариев вряд ли кто-то способен. Особенно, если горит собственная задача.
Конечно, эффективно работать с фрагментом любого размера позволяют инструменты. Если мы говорим о git, то требуется понимать базовые операции, включая commit, rebase, squash, reset, chunk.
Ну, а относиться к ревью кода — как своего, так и чужого — нужно серьёзно. Если вы принимаете изменения, значит утверждаете, что в коде всё хорошо. Не стоит принимать пул-реквесты, не изучив код. В противном случае есть риск попадания некачественного кода в базу, соответственно, повышается вероятность появления ошибок/багов в продукте.
Одобрив код, ревьюер получает свою долю ответственности за поведение продукта уже в продакшне. Многие компании используют этот принцип в ежедневной практике работы — и для многих это весьма полезно.
В целом, код-ревью — очень ценный инструмент в процессе разработки любого программного продукта. И если использовать этот инструмент правильно, то качество таких продуктов повысится, равно как и профессиональный уровень разработчиков команды, где применяется код-ревью.
