С другой стороны, не позволяйте проблемам накапливаться. Костыль способен не выделяться и в целом не портить продукт, если он стоит отдельно. В лучшем случае полтора. Но если в приложении полно ошибок. Не надо.
Что такое Code Review
Понятие обзора кода вошло в обиход очень давно. Буквально это означает: Тестирование, осмотр, проверка и корректировка программного кода. Цель этого задания — найти несоответствия, расхождения и неправильное поведение программного обеспечения. Основной целью обзора кода является улучшение производительности программы. Проверка кода может выполняться специалистом или командой программистов. Процесс рецензирования зависит от сложности задания и может быть проведен как чтение программного кода с учетом наиболее важных моментов или как групповое занятие с дальнейшими выводами о проделанной работе. Хороший обзор кода включает в себя не только поиск несоответствий, но и рекомендации по их устранению, а также обсуждение дальнейших шагов.
Разработчики, создающие программу, всегда знают, как должен быть написан хороший код. Любой специалист, работающий над новым сайтом или приложением, начинает процесс с создания хорошего фундамента. Что означает хороший код? Самое главное — это простота и гибкость. Создавать простой код сложно, это не значит упрощать и сокращать его. Простой код — это максимально возможная ясность процесса. Чтобы определить качество исходного кода, необходимо учитывать несколько моментов:
- Простота понимания кода. Хороший код не должен содержать много запутанных структур. Эксперт должен понимать принцип кодирования без дополнительных объяснений и документации.
- Гибкость кода. Простой, но хорошо продуманный код позволяет вносить исправления и изменения без потери качества. Если исходный код хороший, то можно изменить конфигурацию в будущем.
- Возможность дополнений. Код должен позволять вам создавать новые функции, не боясь нарушить основные алгоритмы.
- Простота эксплуатации. Если возникают проблемы, их нужно уметь быстро решать.
- Доступность. Хороший код требует, чтобы при необходимости его можно было передать другому разработчику для дальнейшей работы. И новый программист может легко разобраться в программе, внести изменения и добавить новые разделы.
Чтобы облегчить процесс разработки нового кода, каждый язык программирования имеет свои стандарты. Таблицы стилей кода подробно описывают процесс расстановки символов, разделения конструкций и пробелов. Неопытные специалисты иногда игнорируют эти стандарты. Это нежелательно, поскольку соблюдение стандартов гарантирует, что следующий работник сможет понять программу.
Тестирование с помощью техники обзора кода позволяет выявить ошибки в коде, разработанном на ранней стадии. Такая тактика помогает избежать непредвиденных ситуаций и расходов в будущем. Можно определить и другие преимущества такого подхода:
- Свежий взгляд. Не последнюю роль в этом процессе играет человеческий фактор. Возможно, что недостаток опыта, усталость или желание упростить работу могут привести к некачественной работе. Свежий взгляд на созданный продукт сразу же выявит все недостатки.
- Трансмиссия. Поскольку в работе задействовано много работников, всегда есть возможность делегировать дальнейшие действия любому из них. В любой непредвиденной ситуации работник может заменить своего коллегу и продолжить работу.
Каждый качественный процесс имеет такой недостаток, как потеря времени. Работа с ревью кода занимает много времени, потому что качественное ревью — это процесс, не допускающий спешки. При планировании графика создания программного продукта необходимо учитывать время на оценку и возможность переноса этапов графика.
Преимущества обзора кода значительно перевешивают недостатки, но должно быть ясно, что его использование не всегда уместно. Есть проекты, в которых такой подход не нужен. Если вы создаете стабильные программы, которые не подлежат изменению, вы можете обойтись без определения кода различными экспертами. Однако если есть тенденция к добавлению новых функций и в будущем появятся новые функции, обзор кода необходим. Если вы планируете большой, долгосрочный проект, всегда есть возможность нанять новых специалистов, расширить аудиторию или внедрить новые технологии. Работа по анализу и оценке поможет вам избежать финансовых затрат и сделать работу быстрее, проще и качественнее. Вот почему многие компании теперь делают обзор кода обязательным пунктом при изменении программного обеспечения, даже если у вас опытный разработчик.
@elain — маска nitpick (некритично) : Не критично, но для единообразия папка с изображениями батута должна называться assets.
Что такое код-ревью
Потому что разработчики просматривают и обсуждают код друг друга.
Время чтения: 6 минут
Обновлено 1 декабря 2021 года
Практика обзора кода очень распространена в индустрии разработки программного обеспечения. Разработчик отправляет написанный им код своим коллегам, которые просматривают его и дают свои отзывы.
Таким образом, могут быть обнаружены потенциальные проблемы, которые автор не заметил. Кроме того, такая практика распространяет знания по всей команде и помогает всем инженерам хорошо разбираться в коде.
Как происходит
Как правило, разработчик представляет на рассмотрение набор изменений, которые решают конкретную проблему, например, добавляют новую функцию или исправляют ошибку. Как правило, разработчик вносит эти изменения в свою ветку и просит коллегу просмотреть изменения, прежде чем слить их с основной веткой.
Изменения передаются на проверку кода через запросы пула. Чтобы пройти проверку кода, необходимо согласие одного или нескольких коллег. Способ отбора коллег для экспертной оценки зависит от процедур, принятых в организации.
Запрос на слияние (PR) — это предложение объединить изменения в одной ветке разработчика с другой веткой. Иногда их также называют запросами на слияние (MR).
Типичный обзор кода для запроса на слияние на GitHub выглядит следующим образом:
В некоторых группах обзор кода необязателен; автор изменения сам решает, нужно ли ему мнение третьей стороны. Таким образом, разработчики получают облегчение, не будучи вынужденными пересматривать большое количество простых изменений. С другой стороны, на автора возлагается большая ответственность за качество написанного кода.
Это хорошо для команды, когда рецензент честно хвалит удачное решение», — говорит Андрей Строгов. Одни считают, что они пишут идеальный код, другие — что их код плох. Вот почему нам важно научиться честно хвалить хорошие решения. Это делает автора кода счастливым и укрепляет отношения в команде.
Проверка на читаемость
Это, вероятно, самая поверхностная часть обзора кода, но она обеспечивает сопровождаемость кода в будущем. Если вы не понимаете код сейчас, вы не поймете его через год.
Каждый написанный вами кусок кода имеет ценность — поддержку. Сделайте одолжение своим коллегам и тщательно проверьте свой код.
Вот несколько вещей, которые вы можете проверить:
- Ищите опечатки (они встречаются повсеместно) в именах переменных и функций, комментариях, описаниях и даже именах файлов.
- Имена классов и функций должны быть хорошо подобраны. Имена функций должны отражать объект, за который отвечает функция.
- Комментарии должны быть четкими и хорошо сформулированными. Это не означает, что они должны быть длинными.
- Последовательность. Код не пишется как отдельный, изолированный фрагмент: Он является частью кодовой базы. Убедитесь, что автор придерживался общепринятых методов при написании кода. Убедитесь, что она согласуется со всеми остальными элементами кодовой базы. Например, для сложных слов могут быть разные написания:
Убедитесь, что проверяемый код согласуется со всем остальным.
- В коде не должно быть никаких выражений. Если вы их обнаружите, то автор, вероятно, забыл удалить их после отладки.
- Избегайте ненужных гнезд.
- Если возможно, результат должен быть возвращен как можно скорее. Если вы видите что-то подобное:
можно изменить следующим образом:
Предложите, что, по вашему мнению, необходимо сделать для улучшения понимания кода.
Фото Nicole Wolf on Unsplash
Проверка функциональности
Как рецензент, вы отвечаете за качество кода, который компания выпускает в производство. Уделяйте внимание деталям, уделяйте внимание масштабируемости и, самое главное, уделяйте внимание безопасности.
- Имеет ли этот процесс смысл?
- Есть ли лишние элементы управления, петли и т.д.?
- Помните о принципе единоличной ответственности для методов и классов. Это делает тестирование более индивидуальным.
- Возможно ли, чтобы функция «упала»? Например, убедитесь, что длина таблицы проверяется перед обращением к ней. Или, по крайней мере, убедитесь, что нет ошибки «нулевого указателя».
- Как бы я это сделал? Мой путь лучше? Может ли эта логика улучшить существующую?
- Тесты меняются не просто так. Например, если тест был использован для проверки того, что функция не выдает ошибку, но затем тот же тест обнаружил, что функция выдает ошибку — спросите, почему. Возможно, было внесено серьезное изменение, влияющее на эту функцию.
- Кроме того, тесты не удаляются без причины. Если вы не знаете, почему тест был удален, спросите. Что, он тебе больше не нужен? Почему?
- Существует несколько тестов для проверки внесенных изменений и их влияния. Однако убедитесь, что тесты подтверждают то, что они должны подтверждать.
Что делать, если я не знаю язык, на котором написан код?
Это классика. Вы не знаете ни языка, ни технологии, но вам следует проверить код, в котором они используются.
Не пугайтесь поначалу. Убедитесь, что другие рецензенты знают язык. Таким образом, вы можете быть уверены, что кто-то другой заметит ошибки, которые не видите вы. Спросите, действительно ли ваш отзыв так необходим.
Хорошей отправной точкой может стать приблизительный набросок. Ищите опечатки и проверяйте правильность выбора имен переменных.
Если вы хотите, вы можете поискать в хранилище другой код на том же языке и попытаться обнаружить закономерности. Помните: если вы чего-то не понимаете, вы всегда можете спросить.
И самый важный совет: не следуйте слепо «лучшим практикам». Всегда сначала спрашивайте. Каждая часть кода должна добавлять ценность продукту. Подумайте о том, как этот код улучшает продукт, а также постарайтесь облегчить жизнь разработчику, которому придется поддерживать его в будущем (а это можете быть вы).
