Очень хорошо про важность code review и его основные правило рассказано в статье CodeProject.
Мы работаем по Git Flow. В этом случае это означает, что ни одна feature не сливается в ветку develop, пока не будет произведено review внесенных разработчиком изменений. В этом участвует либо вся команда, либо ведущий разработчик проекта.
Главное эмпирическое правило - не должно быть ни одной строчки кода, о которой бы знал только ее автор.
Если в результате review выявлены какие-то недостатки - стилистические, логические или архитектурные, ветка отправляется на доработку.
Цель проведения ревью между командами разработки:
- Изучение чужих методов решения задач
- Получение стороннего взгляда и мнения
- Знакомство с большим числом проектов и подходов
При ревью между командами обращаем внимание на:
- Понятность и простоту кода
- Наличие комментариев в сложных случаях
- Соответствие названия методов их содержимому
- Тестируемость кода
- Обоснованность ответственностей объектов
- Соответствие архитектурным и стилевым гайдлайнам
В таких review могут принимать участие все сотрудники отдела. Удобнее всего не просматривать весь проект целиком - на это может уйти не одна неделя, а подключиться к нескольким последним feature-review. Если открытых ревью не окажется, следует просто просмотреть любой функциональный кусок, в который были внесены недавно изменения.
Мы немного автоматизировали процесс:
- Dashboard межпроектных review. Используйте для того, чтобы выбрать наиболее подходящего кандидата для изучения.
- Форма результатов review. Табличка из пункта выше автоматически подцепляет эти результаты.
Мы успели перепробовать много разных инструментов для проведения code review: приватные чаты в Slack, GitLab, Fisheye, но в итоге остановились на Upsource.
Code review приносит гораздо больше пользы, когда проверяющие в курсе всех проблем и задач, которые решал разработчик. Для того, чтобы упростить такую коммуникацию, каждому ревью нужно добавлять описание по шаблону:
# Тема review
Меню действий с постом
# Описание review
Я доработал меню действий над постом (на экране поста и в ячейке). Доступные действия над постом теперь зависят от нескольких факторов:
- Если автор поста - текущий пользователь, то он может редактировать его, перейти к настройкам поста, удалить пост.
- Если пост - в Топе, то этот пост можно спрятать, либо спрятать и пожаловаться.
Кроме того, я реализовал функционал скрытия поста из топа - скрытый пост прячется из таблицы и больше не будет показываться до момента перелогина.
# На что обратить внимание
- Логика удаления поста пока что не реализована.
- Работа с настройками поста - тоже, пока что просто кидаю на соответствующий экранчик.
- "Скрыть" и "Скрыть и пожаловаться" работают абсолютно одинаково.
# Связанные таски
- https://jira.rambler.ru/browse/LJIOS-728
- https://jira.rambler.ru/browse/LJIOS-729
- https://jira.rambler.ru/browse/LJIOS-732