Вы знакомы с Git? Если нет, пожалуйста, прочтите сначала эту статью.
Code Review создан для поддержания уровня качества кода в проекте. Это такой процесс, где код одного разработчика проверяется другими на соблюдение стандартов, качества, поддерживаемости, и продуктивности программы.
Отправка кода на проверку именуется Pull Request, или иногда — Merge Request, и коротко записывается как PR / MR.
PR обычно состоит из одного или нескольких коммитов, сопровождается коротким описанием и ссылкой на Ticket, который решается в этом коде.
В зависимости от правил, обычно требуется от 1 до нескольких Reviewer-ов (проверяющих). Если код соответствует нужным стандартам, ревьюверы подтверждают, что они согласны с этим кодом, нажимая на кнопку «Approve».
Для чего нужен Code Review?
Скорее всего вы разработчик и уже писали код, решающий различные проблемы. Всегда ли вы обращаете внимание на качество своего кода? Есть ли код, который вы писали в спешке, не помня для чего объявили переменную с непонятным именем и где вообще ее использовали?
Конечно же вы так делали, и наверняка не раз (:D сужу по себе).
А теперь представьте, что вы пишите код, который обязательно будут читать, при этом до того как он начнет работать в Production (на рабочей версии проекта).
Насколько повысится качество вашего кода? Вы наверняка начнете трижды думать над тем, как правильно назвать переменную. Как правильно прописать алгоритм и решить проблему самым простым, читаемым и красивым способом.
Это конечно же зависит от уровня разрабочиков, которые будут читать ваш код. Но я думаю все понимают для чего нужен этот процесс и могут помочь в соблюдении качества.
Минусы Code Review
Их куда меньше чем положительных сторон.
При процессе CR, сразу несколько разработчиков тратят свое время на то, чтобы выпустить в Production одно решение определенной задачи. Время разработчика драгоценно и дорого обходится компании.
Посчитайте, как долго другие программисты будут читать уже написанный некачественный код, исправлять его сами, пытаться вникнуть и тд?
В моем понимании это обойдется намного дольше и дороже, чем если проверять код прямо перед его выпуском.
Проблемы стандартизации — они почти всегда всплывают и являются предметом спора между разработчиками. Но обазятельно нужно ввести свой стандарт в команде и строго его соблюдать. Это решение должно избавить вас от многих проблем.
В не особо состоявшихся командах Code Review может доводить даже до конфликтов. Важно писать вежливые замечания, без резких намеков на некомпетентность автора. Также важно отвечать на эти комментарии дружелюбно и не подозревать коллегу в откровенном «затапливании».
У этого процесса даже есть своя техника, с внегласными правилами и способами правильно изъяснить свою мысль.
Поговорим о качестве кода
Четкого определения качества кода попросту не существует.
Приведу основные свойства качественного кода в моем понимании:
- Читабельность — Код не загромажден всякими непонятными запутанными конструкциями, и его легко понять без комментариев и документаций.
- Расширение — Можно внести любые новые параметры и функционал, не ломая имеющийся.
- Гибкость — Его не сложно изменить, поменяв фундаментальную часть или конфигурацию.
- Передача — Качественный код не боишься передать другим разработчикам на поддержку.
- Тестовое покрытие — Он должен быть мксимально покрыт тестами, чтобы любая поломка была диагностирована во время внесения изменений.
Есть очень интересные книги на эту тему, а также статьи и другие источники.
Также можно проверить качество своего же кода, лишь попробуйте открыть и полностью понять свой код, написанный какое-либо время назад. Желательно полгода и более.
Если вы его легко понимаете — то это уже признак неплохого кода. А если ваши коллеги могут прочитать и понять код без особых усилий — то тем более, — вы соблюдаете стандарты качества.
Хорошего вам кода!