신속한 코드 검토를 위한 병합 요청의 3가지 필수 사항
여기에서 리포지토리의 다른 구성원에게 코드 솔루션에 대해 알릴 수 있습니다.
병합 요청에 대한 검토가 가능한 한 신속하게 이루어지도록 합시다.
당신뿐만 아니라 리뷰어를 위해
1. 제목
제목은 좋은 MR에게 매우 중요합니다. 좋은 제목은 MR이 무엇인지 설명해야 합니다.
웹페이지의 SEO 제목으로 생각하십시오.
오해의 소지가 있는 경우 검토자는 핵심 아이디어 또는 병합 요청에 대한 이유를 얻기 위해 열심히 노력해야 합니다.
예를 들어:
나쁜:
Refactoring Components
좋은:
ABC-123: Refactor Login Flow for Better Error Handling
그것은 나에게 말한다 :
2. 간략한 설명
물론 제목이 모든 것을 가질 수는 없습니다.
그래서 설명이 있습니다.
제목을 달성하기 위해 수행한 주요 변경 사항에 대해 간략하게 설명해야 합니다.
위의 MR 제목에 대해 다음과 같은 설명이 적절할 수 있습니다. ""
- Removed unnecessary Props
- Adopted composition of Component and reduced Prop Drilling
- UI Error reporting is unified for a form via the `useErrors` hook
- Inputs are now logic-less allowing better testing
이제 위의 설명을 통해 파일 변경 사항을 예상하고 특정 영역의 코드에 더 많은 관심을 기울일 것입니다.
3. 관련 티켓/발권
일부 티켓으로 코드에 변경 사항이 도입되어야 합니다.
이 티켓은 버그, 기능/스토리, 작업 등이 될 수 있습니다.
티켓의 존재는 리포지토리 외부에서 문서화 및 변경 사유를 허용+유지합니다.
코드 외부의 것들과 함께 코드가 아닌 참가자들과 협업할 수 있습니다.
어떤 경우에는 티켓과 MR이 같은 시스템에 있습니다.
예를 들어 Issues from GH는 PR 티켓입니다.
결론
위의 점들이 리뷰어가 리뷰할 내용을 준비할 수 있게 해준다고 생각합니다.
What would you need as a Reviewer as a must-have?
댓글 💬 또는 Twitter 및/또는
이 기사가 도움이 되었다면 다른 사람들과 공유해 주세요 🗣
블로그를 구독하면 받은 편지함으로 바로 새 게시물을 받을 수 있습니다.
Reference
이 문제에 관하여(신속한 코드 검토를 위한 병합 요청의 3가지 필수 사항), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/time2hack/3-must-haves-for-merge-requests-for-swift-code-review-3gpb텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)