Прежде чем углубляться в детали, давайте рассмотрим следующий сценарий:
Вы стоите в открытом поле, где начали строить дом своей мечты.
Дом - это тщательно спроектированный шедевр с прочным фундаментом и красивым фасадом, гармонирующим с элегантным интерьером.
За домом вы видите длинную очередь людей, все в руках держат маленькие белые конверты. Кажется, они очень хотят помочь по дому.
Здесь два почтовых ящика.
Первый почтовый ящик просто помечен как проблемы («Я не собираюсь об этом говорить, у меня много собственных»).
Второй имеет загадочное название - Pull Requests.
И да, теперь мы поговорим о втором почтовом ящике.
Я надеюсь, что вы все теперь поняли суть дела. Так что есть хорошие самаритяне, которые помогут вам с вашим проектом, и они полны идей !!
Они энергичны, находчивы и обладают супер-образным воображением. ;)
Итак, что вы делаете?
Вы говорите, что это просто, у меня уже есть почтовый ящик, и люди могут отправлять свои запросы, которые я могу просмотреть позже. Очень просто!!
А что вы видите через некоторое время?
Вы перегружены запросами и теряете контекст и контроль над своей кодовой базой… .упси, я имел в виду дом !!
Прекрасный фундамент, заложенный вами, теперь превратился в интересный фундамент, в котором назревает множество вещей.
Например, вы недавно одобрили запрос на постройку ванны, вы посмотрели на дизайн и сказали, что это было бы круто !!
Следующее, что вы видите, это то, что она была построена перед вашим домом и с нет водопровода !!
Человек представил, что вы принимаете ванну посреди природы, и вы были увлечены этой идеей и упустили из виду детали, а сам архитектор был настолько поглощен приведением вещей в действие, что он упустил из виду несколько основных деталей! !
Короче говоря, вам нужна система, чтобы навести порядок. Система, которая может быть тонкой и эффективной одновременно, и вы придумываете определенные руководящие принципы, что нужно, а что нельзя, что нужно и нужно, - вот так родилось создание шаблонов.
Начнем,
Как разработчики, мы несем ответственность не только за устранение проблем или внедрение новых функций, но и за четкое информирование рецензентов о ходе разработки.
Разработчик может сообщить о предлагаемых изменениях кода и их целях посредством подробной документации (PRD, TRD) или других средств связи.
Для улучшения процесса проверки кода настоятельно рекомендуется предоставлять описания для запросов на вытягивание. Описания четко отвечают:
- Что могут ожидать рецензенты при просмотре представленного кода?
- Какие стандарты рассмотрел разработчик перед тем, как отправить свой код на рассмотрение?
- Подумал ли разработчик о предстоящем пути?
А из-за огромного объема нашей работы некоторые из этих вещей может стать трудно отслеживать, и, следовательно, шаблоны PR.
Когда вы инициируете новый запрос на вытягивание для реализованной функции или исправления ошибки в репозитории вашего проекта, вы можете разрешить предварительное заполнение поля описания контрольным списком элементов, относящихся к вашей команде, как контрольный список, представленный в предыдущем разделе. Этот процесс отображения предварительно заполненного поля описания в форме запроса на вытягивание является шаблоном запроса на извлечение.
Как мне это настроить?
Создайте файл с именем pull_request_template.md в корневом каталоге вашего проекта. Вы можете добавлять контрольные списки в соответствии с характером вашего репо.
Ниже приведен образец шаблона, который я использую в своих проектах:
<!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> ## Motivation and Context <!--- Why is this change required? What problem does it solve? Link to PRD, TRD?--> <!--- If it fixes an open issue, please link to the issue here. Add the Linear issue number. --> ## Types of changes <!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) ## Backward compatibility <!--- Does it affects exiting contracts? Have you checked your dependent systems? --> - [ ] API - [ ] DB ## How Has This Been Tested? <!--- Please describe in detail how you tested your changes. --> <!--- Include details of your testing environment, and the tests you ran to --> <!--- see how your change affects other areas of the code, etc. --> ## Migration and deployment details (if appropriate) <!-- add your deployment strategy, for eg: do you need to run some migrations, backfilling --> ## Screenshots (if appropriate): ## Checklist: <!--- Go over all the following points, and put an `x` in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! --> - [ ] My code follows the code style of this project. - [ ] I have checked the **Code Quality Reports**. - [ ] My change requires a change to the documentation. - [ ] I have updated the documentation accordingly. - [ ] I have added tests to cover my changes. - [ ] All new and existing tests passed. - [ ] I have updated my dependent systems. - [ ] My change may put additional load on the system - [ ] I have load tested the system
И БУМ !! Теперь всякий раз, когда кто-то создает новый PR, шаблон описания заполняется заранее, и можно добавлять соответствующие детали.
Итак, что мы поняли?
Настройка PR-шаблона - это очень небольшая задача, но она имеет большое значение для поддержания качества вашей кодовой базы. Иногда это может устранить необходимость в RCA, поскольку некоторые вещи можно обеспечить, следуя контрольному списку, и упущения могут быть устранены.
