Ревью кода
создатель Александр Брянцев
1. Цели
1.1. "Социализация" кода
1.1.1. Распространение знаний о системе
1.1.2. Коллективное владение кодом
1.1.3. Достижение консенсуса
1.1.4. Обучение
1.2. Повышение качества
1.3. Проверка завершения
1.4. Устаревшее
1.4.1. Соответствие стилям и правилам
1.4.2. Устранение ошибок
2. Причины ЗА
2.1. Две пары глаз лучше
2.2. Эффект плюшего мишки
2.2.1. Проговаривание
2.2.2. Другой режим работы мозга
2.3. Выравнивание знаний о системе в команде
2.4. Код "для людей"
3. Причины против
3.1. Личностные конфликты
3.2. Звездная болезнь автора кода
3.3. Может стать скучной процедурой
3.4. Может повысить трудозатраты
3.5. Социальные (критика -> недоверие, обиды)
3.6. Ложное чувство безопасности
4. Степень формальности
4.1. Групповое ревью (inspection,team review)
4.2. Прохождение (walkthrogh)
4.3. Парное программирование (pair programming)
4.4. Рецензия (passaround)
4.5. Целевое ревью (ad hoc review)
5. Стратегия выбора ревьювера
5.1. Авторитетный человек
5.2. Ищешь сам
5.3. В парах
5.4. Контрольный центр, выбирающий ревьювера
5.5. Спец-отряд
5.6. Танцуют все
5.7. Связи на стороне
6. Стратегия ведения ревью
6.1. Замечания
6.1.1. фиксятся сразу
6.1.2. оформляются как задачи
6.2. Кто ведет?
6.2.1. Автор
6.2.2. Ревьювер
7. С чего начать?
7.1. Интерфейсы
7.2. Тесты
7.3. Документация
7.4. Реализация
8. Что ревьюить?
8.1. Изменения
8.2. Всё решение
8.3. Ключевые точки (классы, методы)
9. Как внедрить?
9.1. Общее решение команды
9.2. Начать с малого и медленно
9.3. Адаптировать под себя
9.4. Интегрировать в процессе
9.5. Время будет!
10. Полезные советы
10.1. Проводить до или перед чекином (перед лучше)
10.2. Отслеживать ревьюверов
10.2.1. Он знает код
10.2.2. Статистика перегрузки ревьюверов
10.2.3. Отвественность
10.3. Static code analyser до ревью
10.4. Инспектируем код, а не автора
10.5. НЕ пропускаем ревью
10.6. Ревьювер в курсе задачи
10.7. Должно быть удобным процессом
10.8. Правила ревью д.б. общедоступны
10.9. Документировать ревью
10.10. Ищем достоинства, а не только недостатки
10.11. Тесты тоже требуют ревью
10.12. Есть вопросы, непонятно как работает - спрашиваем
11. Кейсы
11.1. Изменений много
11.1.1. Исправляем
11.1.2. Комитим как есть и ставим задачи
11.2. Примитивные ошибки правим сразу
11.3. Не делаем наспех
11.4. Не затягиваем проведение
11.5. Если ревью не прошло 2 раза - опасность
11.5.1. Меняем автора
11.5.2. Добавляем ревьювера
11.6. Автор не понял смысл замечаний
11.6.1. Программируем в паре