Чжан Юйхан : группа поддержки медицинского страхования отдела передовых технологий WeDoctor, неграмотный программист-Дева.
предисловие
Не бывает любви без причины, ненависти без причины и, конечно, проверки кода без причины.
Почему CR
Позвольте мне рассказать вам историю, «Великий Бог А» внезапно в гневе отругал, когда он пошел на работу,Кто писал этот код, без комментариев и ничего, такой явный баг. В то время вся группа не осмеливалась говорить и запаниковала до смерти, опасаясь, что это были они сами. Лидер сказал: «Великий Бог А», проверьте запись подачи, и тот, кто ее представил, пригласит вас на ужин. Через две минуты "Великий Бог А": Это, этоОтправил сам год назад. Так что не хотите позориться, поспешите на код-ревью
1. Ролевые функции
автор является разработчиком требований. Требовать:
- Обратите внимание на примечания. Пишите соответствующие комментарии для сложных дел и пишите название коммита с конкретным фоном отправки, который легко понять рецензентам.
- Правильное отношение к принятию отзывов других. Комментарий рецензента дается, чтобы не возникало противоречивых эмоций, вы считаете необоснованным предложение, можете вежливо отказаться или подробно описать свое мнение и почему. мнение рецензента не обязательно разумно, поэтому рецензирование представляет собой процесс взаимного обучения.
- Обеспечьте своевременную обратную связь после завершения модификации комментария. commit Информационные примечания фиксации, такие как «reivew: xxxx», чтобы обеспечить эффективность повторной проверки.
Рецензента, как участника CR, рекомендуется составлять из владельца проекта и участников проекта. Требовать:
- Определяет уровень комментария. Когда рецензент оценивает соответствующий сегмент кода, ему необходимо указать соответствующий уровень, например
- fix: здесь требуется изменить xxxxxxx, и даны предложения по изменению
- советовать: xxxxxxx Субъективно предлагаемая модификация здесь, не обязательна, может дать предложения по модификации
- вопрос: xxxxxx Тут есть сомнение и автору нужно пояснить
- Дружелюбный комментарий. Обратите внимание на формулировку оценки, вы можете сказать «как мы можем ее скорректировать и изменить, она может быть более подходящей ...», и следует дать достаточно похвалы за лучший код.
- Наслаждайтесь обзором. Избегайте рецензирования с придирчивым мышлением Хороший рецензент не измеряется количеством заданных вопросов. Выпрыгивание из собственного стиля кодирования и активное понимание идей автора также является хорошим процессом обучения.
2. Процесс CR
1. Самоанализ
- Перед фиксацией попросите diff проверить изменения в файле, после чего gitk сможет завершить. Конечно, если проект использует предварительную фиксацию для связывания проверки lint, также могут быть найдены операторы, такие как отладчик и console.log. Тем не менее, рекомендуется проверять представленные материалы перед каждым представлением.
- Фиксируйте в сотрудничестве с несколькими людьми. Филиалы, работающие с несколькими людьми, должны обращать внимание на то, не вносятся ли ненужные коммиты при запросах на слияние.
- зафиксировать сообщение. Рекомендуется получить доступ к husky, commitlint/cli и commitlint/config-conventional, чтобы проверить сообщение фиксации. Типы, предоставляемые commitlint/config-conventional, похожи на
- Подвиг: новые функции
- исправить: исправить ошибку
- рутинная работа: оптимизация, такая как структура проекта, обновления установки зависимостей и т. д.
- документы: Изменения в документации
- стиль: модификации, связанные со стилем
- рефакторинг: рефакторинг проекта
Эта цель состоит в том, чтобы еще больше увеличить объем информации о сообщении фиксации и помочь рецензентам и самим себе более эффективно понять содержание фиксации.
2, КР
- Инициировал CR, когда спрос, связанный с задач рецензента, упомянутая мерой. СЛЕДУЮЩИЙ ЗАПРОС, чтобы обеспечить, с помощью GitLab / Sourcetree / VSCode Gitlens другие инструменты. После предоставления рецензента обратной связи
- После того, как предложение рецензента будет пересмотрено, в сообщении фиксации будет указана аналогичная информация, связанная с «исправлением проверки», которую рецензенту будет удобно перепроверить.
- Срочные потребности, особые случаи, пропустите ссылку cr и просмотрите позже.
3. Стандарт ЧР
- Не путайте со стилем кодирования. Стиль кодирования передан eslint/tslint/stylelint
- Производительность кода. Обработка больших данных, повторный рендеринг и т. д.
- Комментарии к коду. Полевые примечания, примечания к документации и т. д.
- Читаемость кода. Слишком много вложенности, неэффективный избыточный код, независимость функций, именование методов переменных для удобочитаемости и т. д.
- Расширяемость кода. Разумна ли конструкция функционального метода, разделение модулей и т. д.
- Контролируйте временные затраты на проверку. Рецензент должен максимально состоять из руководителей проекта, обращать внимание на логику кода и не должен понимать слово за словом.
Четвертый, последний
В целом, cr — это не процесс поиска ошибок, и он не снижает общую эффективность разработки. Его цель — обеспечить стандартизацию проекта, чтобы другие разработчики могли сэкономить больше времени и энергии при расширении и поддержке проекта. Конечно, cr-ссылку должен продвигать каждый член команды, только тогда, когда все узнают и будут участвовать в этом, может быть задействовано максимальное значение cr.
Наконец, Amway разработала плагин vscode и gitlab для обзора. Поскольку он включает внутренний код, он пока не может быть открыт для внешнего мира.Вот некоторые идеи на данный момент, а конкретные коды будут открыты позже.