|
|
@@ -0,0 +1,122 @@
|
|
|
+# Лучшие техники ревью кода (Ковалев Никита 47 группа)
|
|
|
+
|
|
|
+### Стандарты код-ревью
|
|
|
+Обзор кода - один и составляющих процессов поддержания качества программного обеспечения. В ходе него один или несколько человек изучают и оценивают программу в основном путем просмотра и чтения отдельных фрагментов его исходного кода.
|
|
|
+
|
|
|
+Проверка исходного кода вручную или автоматически (с помощью специальных инструментов обзора кода) является частью процесса мониторинга качества программы. Это делается для поиска и исправления ошибок, изучения соответствия стандартам кодирования, читабельности и ремонтопригодности кода, наличия дубликатов и т.д. Каждая часть программного обеспечения или новая функция, создаваемая разработчиками компании, проверяется на качество.
|
|
|
+
|
|
|
+Создание надежной процедуры проверки кода закладывает основу для непрерывного развития продукта и предотвращает выпуск небезопасного для пользователей кода. Чтобы повысить качество кода и убедиться в том, что каждый фрагмент кода был просмотрен другим членом команды, методы код-ревью должны быть включены в повседневную работу команд, разрабатывающих программное обеспечение.
|
|
|
+
|
|
|
+При проведении код-ревью следует помнить о следующих вещах, необходимых для эффективного результата:
|
|
|
+
|
|
|
+* Обзор кода должен быть быстрым, со своевременными ответами и обратной связью. Анализ кода должен проводиться сразу после выдвижения нового кода, чтобы разработчик мог получить моментальную обратную связь.
|
|
|
+
|
|
|
+* Анализ кода должен развивать и учить. Поскольку основной целью процесса является повышение качества кода, проводимые обзоры должны стать средством обмена знаниями и опытом между коллегами.
|
|
|
+
|
|
|
+* Обзор кода должен сопровождаться тестами. Без проведения необходимых тестов, обзор может оставить не устраненные ошибки и проблемы с безопасностью в коде.
|
|
|
+
|
|
|
+* Комментируйте и поощряйте хорошее кодирование после обзора кода. Стоит дать понять владельцу кода, что он хорошо справляется со своей работой. Обзор кода служит не только для поиска ошибок, но и для поощрения программистов.
|
|
|
+
|
|
|
+* Обзоры кода должны следовать стандартным практикам кодирования. Ревью кода не стоит строить на индивидуальных предположениях, необходимо следовать общепринятым принципам, на которые можно ссылаться и цитировать. Это необходимо для того, чтобы все придерживались стандартов кодирования, руководств по стилю и принципов языка, принятых для разработки программ.
|
|
|
+
|
|
|
+* Результаты ревью нередко могут стать причиной разногласий между ревьюером и разработчиком. Программист может не принимать корректность и актуальность выдвигаемых замечаний. Подобные споры следует разрешать, придерживаясь общепринятых практик, изложенных в руководстве по стандартам стиля кодирования, а также учитывая мнения специалистов, обладающих большим опытом в рассматриваемой области.
|
|
|
+
|
|
|
+### Примеры комментариев к ревью кода:
|
|
|
+
|
|
|
+1) Повышение эффективности кода:
|
|
|
+
|
|
|
+* "Рассмотрите возможность использования словаря вместо цикла для проверки существования элемента в списке".
|
|
|
+
|
|
|
+* "Этот участок кода можно рефакторить, чтобы использовать выражение-генератор".
|
|
|
+
|
|
|
+2) Улучшение читабельности:
|
|
|
+
|
|
|
+* "Имя переменной 'temp' недостаточно описывает ее, пожалуйста, придумайте более осмысленное имя".
|
|
|
+
|
|
|
+* "Функцию можно сделать более читабельной, добавив к ней doc-строку, объясняющую ее назначение".
|
|
|
+
|
|
|
+3) Обработка ошибок:
|
|
|
+
|
|
|
+* "Этот код не обрабатывает исключения должным образом, пожалуйста, добавьте блок try-except для обработки возможных ошибок".
|
|
|
+
|
|
|
+* "В данном случае не следует возвращать None, подумайте о том, чтобы вместо этого выбросить исключение".
|
|
|
+
|
|
|
+4) Безопасность:
|
|
|
+
|
|
|
+* "Убедитесь, что пользовательский ввод санирован правильно, чтобы избежать атак XSS и SQL-инъекций".
|
|
|
+
|
|
|
+* "Рассмотрите возможность использования библиотеки типа hashlib для безопасного хэширования паролей вместо модуля sha256".
|
|
|
+
|
|
|
+5) Тестовое покрытие:
|
|
|
+
|
|
|
+* "Этому коду нужно больше тестовых примеров, чтобы обеспечить полное покрытие и предотвратить регрессии".
|
|
|
+
|
|
|
+* "Пожалуйста, добавьте отрицательные тестовые случаи, чтобы проверить поведение кода в непредвиденных ситуациях".
|
|
|
+
|
|
|
+6) Стандарты кода и лучшие практики:
|
|
|
+
|
|
|
+* "Функция не должна иметь побочных эффектов, пожалуйста, отрефакторите ее, чтобы она возвращала только значение".
|
|
|
+
|
|
|
+* "Избегайте использования глобальных переменных, вместо них используйте свойства класса или аргументы функций".
|
|
|
+
|
|
|
+### Лучшие практики ревью кода
|
|
|
+
|
|
|
+* Установите цели и стандарты компании. Перед началом процесса обзора кода очень важно выбрать ключевые показатели и установить четкие цели. Цели компании должны ставиться с учетом соответствующих стандартов программирования. Установив свои стандарты, компания должна гарантировать, что любой программный продукт, который она разрабатывает, будет соответствовать требованиям.
|
|
|
+
|
|
|
+* Создайте чек-лист для проверки кода. Чек-лист состоит из установленных наборов рекомендаций и вопросов, которых придерживается компания на протяжение всего процесса проверки кода. Это дает компании преимущество организованного подхода к необходимым проверкам качества кода, перед его утверждением в кодовой базе.
|
|
|
+
|
|
|
+* Установите некоторые метрики для обзора кода. Степень повышения качества кода должна каким-то образом оцениваться. Используя объективные метрики, вы можете изучить влияние запросов на изменения и оценить эффективность ваших оценок.
|
|
|
+
|
|
|
+* Ограничьте количество строк кода для обзора за один раз. Это необходимо для того, чтобы обзор проходил с одинаковой эффективностью.
|
|
|
+
|
|
|
+* Дайте положительную обратную связь на обзорах кода. Исходный код может быть результатом парного программирования, поэтому полезно давать обратную связь для позитивных изменений и рекомендаций.
|
|
|
+
|
|
|
+### Пример чек-листа ревью кода
|
|
|
+
|
|
|
+1) Структура кода:
|
|
|
+
|
|
|
+* Правильные отступы и форматирование
|
|
|
+
|
|
|
+* Согласование правил именования и четкой организации кода
|
|
|
+
|
|
|
+* Комментирование и документация
|
|
|
+
|
|
|
+2) Производительность:
|
|
|
+
|
|
|
+* Эффективность и оптимизация кода
|
|
|
+
|
|
|
+* Избежание ресурсоемких операций
|
|
|
+
|
|
|
+3) Безопасность:
|
|
|
+
|
|
|
+* Валидация и санация ввода
|
|
|
+
|
|
|
+* Практика безопасного кодирования (например, предотвращение SQL инъекций)
|
|
|
+
|
|
|
+* Защита от распространенных угроз (например, XSS)
|
|
|
+
|
|
|
+4) Функциональность:
|
|
|
+
|
|
|
+* Правильное и ожидаемое поведение кода
|
|
|
+
|
|
|
+* Обработка и отладка ошибок
|
|
|
+
|
|
|
+5) Тестовое покрытие:
|
|
|
+
|
|
|
+* Правильное тестирование и покрытие кода
|
|
|
+
|
|
|
+* Правильные тестовые кейсы и условия тестирования
|
|
|
+
|
|
|
+6) Стандарты кода и лучшие практики:
|
|
|
+
|
|
|
+* Соблюдение профессиональных стандартов и соглашений
|
|
|
+
|
|
|
+* Возможность повторного использования, сопровождаемость и масштабируемость
|
|
|
+
|
|
|
+* Правильная обработка ошибок и исключений
|
|
|
+
|
|
|
+### Заключение
|
|
|
+Основная цель код-ревью - обеспечить общее качество и безопасность программной системы. Рецензирование кода коллег не должно быть пугающим или разочаровывающим. Установите стандарты для обзора кода, введите метрики и используйте инструмент автоматизации, чтобы помочь в процессе анализа исходного кода для изменений и улучшений.
|
|
|
+
|
|
|
+### Литература
|
|
|
+<https://habr.com/ru/articles/716068/>
|
