Введение в код - ревью

1. Введение в код-ревью

Введение в кодревью

2. Процесс ревью (Что нужно делать?)

• Отсматриваем ПР-ы на дев/тест стенды
• Фиксируем комментарии в битриксе/калитеа
• Комментарий должен однозначно указать на место
замечания и полностью доносить техническую суть
• Завершаем этап ревью переводя реквест в статусы NEEDS
WORK / APPROVED
• Отвечаем на комментарии разработчика, консультируем
очно/онлайн при необходимости
• Ждем исправления – повторяем процесс

3. На что обращать внимание

Краткие теги, подробнее в регламенте ЦК Разработки

4. Форматирование

Проверяем:
• Форматирование всех типов файлов: TS, JS, SCSS, HTML
• Соответствие настройкам prettier
• Соответствие общим настройкам проекта
Аргументация:
Читаемость
Конфликты при слиянии
Единообразие

5. Архитектура – Структура папок – Используемые библиотеки

Проверяем:
• Единообразие
• Соответствие проектным подходам
• Лучшие практики
• Безопасность / актуальность версий

6. Целесообразность

Проверяем:
• Функциональная/бизнес необходимость данного кода
• Наличие действующих или типовых решений (велосипеды)
• Лучшие практики

7. Расположение кода

Проверяем:
• Код логически и тематически размещен в структуре
проекта
• Компонентный подход
• Целевое использование компонентов, стора, пайпов,
сервисов, директив и.т.д.

8. Наименования / Code style

Проверяем:
• Соответствие Angular Code Style, регламентам в будущем
• Понятность, лаконичность наименований (говорящие
наименования)

9. Качество кода

Проверяем:
• Основы JS
• Типизация TS
• Основы RxJs
• Паттерны
• Работа со Store

10. Быстродействие/безопасность

Проверяем:
• Функции в шаблоне
• Лази-лоадинг
• Подписки-отписки
• Вызовы сервисов
• Хранение, передача в открытом виде уязвимой
информации
• Работа со списками/массивами
• Debugger/console.log

11. Советы по процессу

Рекомендации для ревьюера

12. Сохраняем артефакты

• Ведем переписку приоритетно в комментариях к пр-у
• Второстепенно в рабочих чатах

13. Отработка возражений

• Срочность: по умолчанию разработчик закладывает время
на прохождение ревью. Исключения : Релизы, показы
• Перекладывание ответственности: Разработчик несет
ответственность за вносимые изменения и за код
входящий в контекст этих изменений
• Отложенный рефакторинг: Код должен попадать на стенды
после прохождения ревью, форматы рефакторинга
«потом» не рассматриваем. (Исключения описаны выше)

14. Фокусирование на цели ревью

• Единственная техническая оценка
• Минимализация рисков для компании
• Развитие разработчиков

15. Эскалация

Ситуации, в которых необходимо эскалировать (поднять
флаг), обратиться к техлиду:
• Конфликтные ситуации, бескомпромиссные/полярные
мнения
• Выявленный техдолг на проекте, за рамками изменений в
пр-е. Необходимость глубокого рефакторинга
• Любые проектные риски

16. Развитие ревьюера

• Насмотренность проектная
• Насмотренность техническая
• Погружение в контекст