Что в основном проверяет Code Review?

JavaScript

Что такое обзор кода?

Проверка кода (Code Review) означает сознательный и систематический призыв к другим программистам проверять код друг друга на наличие ошибок.

Обычно проверка кода приводит к следующим последствиям:

  • Улучшайте качество кода и его ремонтопригодность, читабельность и т. д.
  • Проверьте наличие упущений, найдите потенциальные проблемы и т. д.
  • Лучшие практики, способы делать вещи лучше и быстрее.
  • Когда вы делитесь знаниями и просматриваете код других людей, это на самом деле процесс обучения, и вы также будете размышлять и подводить итоги.

Почему код-ревью?

Решение о том, следует ли проводить проверку кода, следует принимать в зависимости от текущей среды и ситуации. Если задача разработки команды проекта чрезвычайно сложна, то проведение проверки кода в это время может иметь неблагоприятные последствия. поиск точек соприкосновения при сохранении разногласий — основа код-ревью.

Code Review особенно нуждается в общении и сотрудничестве с членами команды проекта, а также в проверке технического уровня каждого члена.

В частности, следует отметить, что люди обладают инерцией, и у каждого есть свой набор стандартов и норм поведения, и если они хотят унифицировать свое поведение или нормы, им легко сопротивляться.

Перед Code Review хорошо общайтесь с участниками проекта, имейте общее видение и помогите с соответствующим обучением, чтобы компенсировать недостатки некоторых сотрудников, это облегчит некоторый дискомфорт участников проекта и сделает проект более плавным.

В то же время мы также должны обратить внимание не на то, чтобы стремиться к перфекционизму во всем, а на то, чтобы добиться успеха за один шаг, мы должны знать, что «медленное — это быстро».

Предпосылки для проверки кода

Сам Code Review относится к работе «постфактум», которая может играть роль проверки утечек.

При внедрении Code Review необходимо заранее подготовить следующие задачи, чтобы команда могла принять и внедрить его быстрее и качественнее.

  • Спецификации сборки, в том числе:
    • Соглашения о кодировании, такие как имена переменных, соглашения об именах файлов и т. д.
    • Принципы проектирования, такие как принцип единой ответственности, принцип наименьшего знания и т. д.
    • Стратегия управления филиалом
  • Полная документация для легкого доступа
  • Разработайте процесс и цели Code Review, а также цикл реализации.

Например, в проектной команде, которую я сейчас возглавляю, внедрение Code Review разделено на 3 этапа по степени сложности.

  • Первый этап, фокусирующийся на правильных аннотациях функций, «жестко закодированных» проблемах, общих правилах именования переменных и т. д., ожидаемый период реализации составляет 1–3 месяца.
  • На втором этапе основное внимание уделяется связыванию кода, единой ответственности, принципу наименьшего знания, потенциальным скрытым опасностям, проблемам с производительностью и т. д. Ожидаемый период реализации составляет 3–6 месяцев.
  • Третий этап, фокус, схема реализации модуля, рисунок дизайна, лучшая практика, рефакторинг кода и т. Д.

В процессе внедрения, если есть относительно большое сопротивление или трудности, а преимущества, полученные от внедрения Code Review, невелики, вы можете рассмотреть возможность надлежащего «отдыха» в течение определенного периода времени.

Как реализован код-ревью?

Из опыта процесса реализации текущего проекта, а также опыта других людей в Code Review предлагается:

  • Проверка не более 500 строк кода за раз ограничит человеческую энергию.Если вы просматриваете слишком много кодов за раз, преимущества могут быть не идеальными.
  • Рекомендуемая продолжительность одного обзора не более 30 минут.

Общие элементы проверки кода

спецификация коммита git

спецификация фиксации фиксации git, например:

  • информация не отмечена
  • Не совершить вовремя
  • Информация, отмеченная при подаче, не стандартизирована и т.д.

Это один из факторов, который серьезно мешает обзору.Помимо условной информации описания, вы можете также примечания по типу:

  • подвиг: новые возможности
  • исправить: решить проблему
  • рефакторинг: рефакторинг кода
  • документы: Изменения в документации
  • работа: другие модификации
  • тест: модификация тестового примера
  • стиль: модификация формата кода и т. д.

Конечно, некоторые инструменты должны помочь нам в выполнении основных ограничений и проверок, например:Используйте Git изящно

стиль

1. Удобочитаемость

Для измерения удобочитаемости существует стандарт хорошей практики, то есть очень ли легко понять логику кода во время Code Review, если нет, значит, удобочитаемость кода нужно улучшить.

2. Именование

  • Именование очень важно для удобочитаемости, я лично предпочитаю, чтобы не имело значения, если имя функции/класса длиннее, но должно быть ясно, что делает функция/класс.
  • Стоит использовать английские слова как можно точнее, даже если вам нужно использовать средства перевода, но есть одна вещь, на которую следует обратить внимание: если используемые слова очень непопулярны и их никто не знает, то не используйте их .

3. Длина тела функции/длина класса

  • Тело функции слишком длинное и трудночитаемое, обычно рекомендуется не более 50 строк.
  • Если класс слишком длинный, например более 10 000 строк, может потребоваться проверить, не нарушает ли он принцип «единой ответственности».

4. Количество параметров

Не слишком много, как правило, не более 5, более 5, рекомендуется использовать объект

5. Примечания

Только правильные комментарии могут помочь нам понять роль функций/классов.

Архитектурный дизайн

1. Принцип единой ответственности

Это принцип, который часто нарушается, и его труднее всего правильно применить.

  • Класс делает только один класс связанных вещей
  • Функция/метод, желательно что-то одно

2. Является ли поведение однородным?

1) Что такое поведенческое единство? Например:
  • Является ли обработка ошибок единообразной?
  • Является ли сообщение об ошибке однородным?
  • Является ли всплывающее окно унифицированным?
  • ...
2) Та же логика/поведение, выполняется ли один и тот же путь кода

низкое качествоОсобенностью кода является то, что когда одна и та же логика/поведение запускается в разных местах или разными способами, один и тот же путь кода не выполняется (выдавая разные результаты), либо везде копируется копия реализации, что делает его очень сложно поддерживать.

3. Загрязнение кода

Сильно ли код связан с другими модулями?

4. Дублирующийся код

В основном это зависит от того, извлекаются ли общие компоненты, повторно используемый код и функции.

5. Принцип «открыто-закрыто»

Простое понимание состоит в том, чтобы увидеть, можно ли расширить код или нет.

6. Надежность

  • Имеют ли базовые данные обязательную проверку?
  • Был ли бизнес признан завершенным, а логика надежной?
  • Есть ли потенциальные ошибки?
  • Есть ли утечки памяти, есть ли циклические зависимости?

7. Обработка ошибок

Есть ли хорошая обработка ошибок, таких как сетевые ошибки, ошибки ввода-вывода и т. д.

8. Интерфейсно-ориентированное программирование / объектно-ориентированное программирование интерфейса

В основном это зависит от того, есть ли подходящая абстракция, а некоторые поведения абстрагируются в интерфейсы.

9. Эффективность/производительность

  • Правильно ли клиентская программа обрабатывает трудоемкие операции, такие как частые сообщения и большие данные
  • Какова временная сложность ключевого алгоритма и есть ли потенциальные узкие места в производительности?

10. Рефакторинг кода

  • Исправлены ли новые изменения, чтобы продолжать ухудшать качество кода, или они помогут улучшить качество кода?

Общие характеристики некачественного кода

  • Нарушение принципа единой ответственности
  • Одна и та же логика/поведение, запускаемая разными способами, не выполняет один и тот же путь кода.
  • отсутствует аннотация
  • Имена функций/классов искажены, слова не имеют смысла или «подкрадываются», например.
export function setDefaultImg(res) {
    let imgUrl = getImagePrefixUrl()
    let previewImgSrc = require('@/asserts/images/icon.png')
    if(res.imgId) {
        previewImgSrc = `${imgUrl}${res.imgId}.${res.type}?t=${+new Date()}`
    }
    return previewImgSrc
}

Функция в приведенном выше примере на самом деле хочет оценить входящие параметры.Если значение недопустимо, возьмите изображение по умолчанию, в противном случае верните относительный адрес img src с хорошим адресом сплайсинга.Из реализации функции есть следующие проблемы:

  • Имя функции setDefaultImg не подходит, обновления/модификации данных нет, конечная цель - получить адрес склейки img (или образ по умолчанию)
  • формальный параметрresЭто объект, и фактически используются только два основных типа свойств.Следуя принципу наименьшего знания, формальные параметры должны быть изменены.
  • let imgUrl, на самом деле является префиксом URL-адреса соединения, называемого какimgPrefixUrlбыло бы более уместно.
  • let используется неправильно, как вlet imgUrl, так как переназначение переменных не задействовано, используйтеconst是比较合适的
  • res.imgId, то есть обработка нештатных ситуаций, менее корректнаяres.typeобработка
  • имена переменных, напримерpreviewImgSrcИспользование этого имени нецелесообразно. Цель использования SRC неясна. Рекомендуется использовать имя с относительно универсальным значением.

Рассмотрите возможность рефакторинга:

export function getImgSrc(imgId, imgType) {
    if(typeof imgId !== 'string' || typeof imgType !== 'string') {
        return require('@/asserts/images/icon.png')
    }
    return `${getImagePrefixUrl()}${imgId}.${imgType}?t=${+new Date()}`
}

Ссылки по теме

Категории