튜토리얼: Merge Request 검토

Merge Request 리뷰는 코드베이스에 고품질 코드만 포함되도록 하는 데 도움이 됩니다. 이 튜토리얼에서는 GitLab에서 Merge Request을 리뷰하는 방법을 안내합니다. Merge Request 자체의 구조를 안내한 후 건설적이고 유익한 피드백을 제공하는 과정을 안내합니다. 튜토리얼을 마치면 Merge Request을 승인하거나 추가 변경을 요청할 준비가 됩니다.

개요는 여기를 참조하세요: Merge Request 리뷰.

Merge Request을 리뷰하려면:

Merge Request으로 이동
Merge Request의 구조 이해
상위 수준 개요
코드 변경 내용 읽기
리뷰 완료
1. 리뷰 코멘트 작성
2. 리뷰 요약
정리 작업 수행

시작하기 전에

프로젝트에서 Merge Request을 볼 수 있는 권한이 필요합니다.
리뷰할 준비가 된 Merge Request이 필요합니다.

Merge Request으로 이동

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
둘 중 하나:
- 리뷰 요청 페이지로 이동하려면 Shift + r을 누릅니다.
- 왼쪽 사이드바에서 Merge Request () > 리뷰 요청을 선택합니다.

Merge Request의 구조 이해

Merge Request에는 네 가지 옵션이 있는 보조 메뉴가 있습니다. 리뷰 중에 이러한 영역을 서로 다른 시점에 사용합니다:

개요: Merge Request의 설명, 현재 Merge 가능성에 대한 보고, 코멘트가 있는 활동 영역 및 더 많은 정보가 있는 사이드바를 포함합니다.
커밋: 이 Merge Request에 있는 커밋의 디렉터리입니다. 최신 커밋이 먼저 표시됩니다.
파이프라인: 이 Merge Request의 내용에 대해 실행된 CI/CD 파이프라인 디렉터리입니다.
변경 사항: 제안된 변경 사항의 차이점을 보여주는 이 Merge Request의 diff입니다. 삭제된 줄, 추가된 줄, 변경된 줄이 표시됩니다.

개요 탭의 사이드바에는 Merge Request 자체에 대한 중요한 메타데이터가 포함되어 있습니다: 담당자, 리뷰어, 레이블, 마일스톤, 시간 추적 등.

Merge Request의 상위 수준 개요 가져오기

코드를 리뷰하기 전에 Merge Request을 높은 수준에서 평가해야 합니다. Merge Request의 컨텍스트와 목적을 이해하고 해당 요청이 하려는 일과 그 목적을 이해해야 합니다. 이러한 필요성을 스킬셋과 비교하면서 다음 질문을 스스로에게 물어보세요:

Merge Request 뒤에 숨겨진 이야기는 무엇인가요? 생각 깊은 리뷰를 수행할 충분한 배경지식을 갖고 있나요?
요청된 리뷰의 유형과 깊이는 무엇인가요? 예를 들어, 좁은 범위의 버그 수정과 심층적인 아키텍처 리뷰는 매우 다른 리뷰 기대치를 가질 것입니다.
이 작업을 리뷰할 적절한 사람인가요? 이 작업이 필요로 하는 리뷰 유형이 여러분의 기술과 능력과 일치합니까?

먼저 Merge Request의 설명을 살펴보세요. 이 설명은 문제의 해결책이나 이슈에서의 기능 요청이어야 합니다.

저자는 누구인가요? 이 사람의 작업을 알고 있나요? 이 사람을 알면 일반적으로 이 사람이 주로 작업하는 코드베이스의 어느 부분입니까? 나중에 저자에 대한 지식은 변경 사항을 어떻게 검토할지 판단하는 데 도움이 됩니다.
목표는 무엇인가요? 설명을 읽어서 저자의 의도를 이해하세요.
초안인가요? 초안은 종종 완전하지 않거나 이론적인 해결책일 수 있습니다. 초안 Merge Request은 완전히 완성된 Merge Request보다 다른 수준의 검토가 필요할 수 있습니다.
문제를 어떻게 재현할 수 있나요? 이 Merge Request이 버그 수정이라면 설명에서 문제를 어떻게 재현하는지 설명합니까? 변경 사항을 테스트하는 방법을 설명합니까? 여러분을 안내할 스크린샷이 포함되어 있나요?

설명 아래에 있는 Merge Request 위젯을 확인하여 이 작업의 현재 상태를 이해하세요. 이 예시는 승인이 누락되었고 초안 모드인 Merge Request이 있는 Merge 위젯을 보여줍니다:

이슈에 연결되어 있나요? 설명과 Merge 위젯에서 다른 이슈에 대한 링크를 확인하세요. 일부 Merge Request은 간단하지만 일부는 Merge Request이 왜 그런지 이해하려면 해당 이슈를 읽어야 할 수 있습니다. 보다 복잡한 Merge Request은 완전한 정보가 포함된 이슈로 되돌아가야 합니다.
파이프라인 상태는 무엇인가요? 파이프라인은 초록색인가요? 빨간색 파이프라인은 문제를 나타냅니다. 불완전하거나 취소된 파이프라인이 있으면 작업의 전체 Merge 가능성을 평가할 수 없습니다.

사이드바 확인

어떤 레이블이 있나요? 레이블은 Merge Request의 내용에 대한 단서를 제공할 수 있습니다. 여러분의 팀의 작업 흐름에 따라 불완성 또는 누락된 레이블이 무해할 수도 있고, 이 Merge Request에 완전한 정보가 부족할 수도 있습니다.
- 레이블이 여러분의 전문 분야와 일치한다면, 이 Merge Request을 검토하는 좋은 후보가 될 것입니다.
- 레이블이 여러분의 전문 분야와 일치하지 않는 경우, 다른 리뷰어에게 Merge Request을 재할당해야 할 수도 있습니다.
- 여러분의 작업 흐름이 예상하는 레이블을 추가하세요.
이 예시에서 여러분이 정확한 레이블을 모르더라도, 이 Merge Request이 데이터베이스 버그에 관한 것임을 결정할 수 있습니다:
리뷰어는 누구인가요? 리뷰어 디렉터리의 이름을 스캔하세요. 설명과(옵션으로) 레이블을 기준으로 하여 예상한 작업 유형에 일치하는 사람인가요? 그 이름들이 이 Merge Request이 리뷰 사이클에서 어디에 있는지에 대해 여러분에게 어떤 정보를 전달하나요? 누구를 추가하거나 제거해야 할 필요가 있나요?
리뷰어 중 이미 승인한 사람이 있나요? 리뷰어와 그들의 전문 분야를 알고 있다면, 제안된 변경 사항의 어떤 측면에 주의를 기울여야 하는지에 대한 아이디어를 얻을 수 있습니다.
이 예시에서 Thomas와 Nick은 리뷰어입니다. Thomas는 아직 Merge Request을 리뷰하지 않았습니다 (). Nick은 이미 리뷰를 하고 승인했습니다 ():

코멘트 확인

개요 페이지에서 저자와 다른 사람들이 남긴 코멘트를 읽어보세요. 코드 변경 사항을 읽을 때 해당 토론을 기억하세요.

코멘트에 이전 리뷰의 증거가 있는지 확인하십니까? 많은 수의 코멘트는 이 작업을 얼마나 심층적으로 검토할지에 영향을 미칠 수 있습니다.

코드 변경 사항 읽기

이제 제안된 변경 사항을 읽을 준비가 되었습니다. 큰 Merge Request의 경우, 다음 단계로 나아가기 전에 변경 사항을 대강 훑어보세요. 변경 사항을 한 줄씩 읽기 전에 무엇을 기대해야 하는지 이해도를 높이세요.

참고: 변경 사항 탭에 표시된 차이점은 정보로 가득합니다. 이 페이지에서 최대한 많은 정보를 얻는 방법에 대해 자세히 알아보려면 Merge Request의 변경 사항을 참조하세요.

개요를 위한 변경 사항 대강 보기

변경 사항 페이지를 처음 열 때, 먼저 넓은 세부 사항에 주목하세요:

어떤 파일이 변경되었나요? 파일 브라우저()를 확장하여 변경된 파일 디렉터리을 확인하세요. 이 파일들에 익숙한가요? 이 파일들이 코드베이스의 어느 부분에 속하는가요?
파일 디렉터리이 기대와 일치하나요? 이미 Merge Request의 설명을 읽었습니다. 이 작업에 대해 변경된 것을 기대했던 파일들인가요? 예상치 못한 파일의 변경이나 예상했던 변경 사항이 누락된 경우 특히 주의하세요.
라인이 추가, 제거, 또는 변경되었나요? 이 숫자들은 깊이 있는 읽기에서 기대해야 하는 작업 유형을 알려줍니다: 새로운 기능, 제거된 기능 또는 행동의 변경?
어떤 테스트가 변경되었나요? 이 파일들 중 일부가 테스트 스위트에 속하는지 확인하세요. 그렇지 않은 경우, 저자에게 테스트 업데이트를 요청해야 할 수 있습니다.
피처 플래그가 사용되었나요? 피처 플래그를 본다면, 깊은 읽기에서 그 사용을 검토하세요.

변경 사항을 대강 훑어본 후, 준비가 되면 변경 사항을 한 줄씩 읽을 준비가 된 것입니다!

각 파일을 심층적으로 조사

이제 본 Merge Request에 포함된 변경 사항에 대해 넓은 아이디어를 가지게 되었습니다. 이제 전체 변경 사항을 세심하게 살펴보고 읽는 시간입니다. 지식이 있는 곳과 없는 곳을 기억하십시오. 이 프로젝트를 잘 알고 있나요? 변경 사항이 작업하기 편한 언어로 작성되었나요?

변경 사항이 명확하고 이해하기 쉽나요?
피처 플래그가 사용되었나요? 변경된 사항이 피처 플래그의 존재나 부재를 테스트했는지 확인하세요. 피처 플래그별로 변경 사항이 비활성화될 때 우발적으로 유출되지 않도록하세요.
성능이 괜찮나요? 스스로 성능을 테스트하기 편한가요, 아니면 더 심층적인 성능 지식을 가진 리뷰어를 추가해야 할까요?
단순화할 수 있을까요?
특이한 경우를 고려하나요?
주석이나 문서가 올바르게 달렸나요? 좋은 코드는 저자 뿐만 아니라 다른 사람들도 유지보수할 수 있게 합니다. 이 작업을 유지보수할 수 있도록 충분한 설명이 제공되었나요?
팀의 스타일 기대에 부합하나요?
역호환성이 있나요? 이 작업이 파괴적인 변경인가요? 데이터 손실을 일으킬 수 있나요?
보안 문제가 해결되었나요? 프로젝트의 특별한 보안 문제가 있는 영역에 변경 사항이 있는지 확인하세요. 민감한 데이터를 처리하는지, 사용자 입력을 수용하고 필터링한 것인지 확인해야 할까요? 성능 지식을 가진 리뷰어를 추가해야 할까요?
디버깅 문구가 남아 있나요?

다른 유형의 변경 사항은 코드베이스에 다른 영향을 미칩니다. 일반적인 측면에서 고려해보세요:

추가된 라인: 새로운 코드는 기존 동작을 수정해서는 안 됩니다. 새로운 동작들이 테스트되었나요? 테스트가 충분히 세분화되어 있나요?
제거된 라인: 삭제가 깨끗하고 완전한가요? 삭제된 코드와 테스트가 서로 일치하는지 확인하세요. 부분적인 스텁이 둔튼지 않도록 주의하세요.
수정된 라인: 추가된 라인과 제거된 라인이 대략적으로 같다면, 변경은 기존 코드의 리팩터링인가요? 리팩터링이라면, 이전 코드가 무엇을 했고 새로운 코드가 어떻게 다른지 이해했나요? 변경된 동작이 저자가 설명한 의도와 일치하는가요? 테스트가 여전히 올바르게 작동하는지 확인하세요.

코드 테스트

안타깝게도 여기서는 많은 지침을 제공할 수 없습니다. 각 프로젝트 마다 다르기 때문입니다! 애플리케이션을 직접 알지 못하는 상황에서는 변경 사항을 테스트하는 방법을 알려드릴 수 없지만 고려해야 할 몇 가지 질문이 있습니다:

작동하나요? 간단한 질문일 수 있지만 중요합니다. 코드는 못생기고 복잡하며 문서화되어 있지 않을 수 있지만 여전히 작동할 수 있습니다.
리뷰 프로세스는 어느 정도 진행됐나요? 리뷰 프로세스가 초기에 있거나 끝부분에 있나요?
- 프로세스가 초기에 있으면 코드가 저자가 중심으로 작동한다고 확인해야 합니다. 이렇게 하면 코드에 시간을 허비할 필요가 없거나 해서는 안되는 코드에 더 많은 사람이 시간을 허비할 수 있도록 막아줍니다.
- 프로세스가 후반에 있으면 기능이 광고된 대로 작동하는 것을 보장하는 데 관여하지 않을 수도 있지만 스타일과 유지 관리에 더 집중할 수 있습니다.
- 특정한 리뷰어는 특정한 부분에 대해서만 Merge Request을 리뷰할 수 있습니다.

코드를 테스트하는 동안에 파이프라인 상태를 확인해야 합니다. 아직 리뷰 코멘트를 작성하지 않았지만, 이제 거의 준비된 상태입니다.

파이프라인 확인

Merge Request의 파이프라인 탭으로 이동하고 파이프라인 상태를 확인하세요. 오직 파이프라인이 성공한 경우에만 Merge Request을 승인하세요. 이 예제에서 여러 작업이 실패했습니다:

예상했던 테스트가 모두 실행되었나요? 파이프라인이 단순히 녹색이냐 아니면 완료되었는지 확인하세요.
어떤 테스트가 실패했나요? 실패한 작업을 확장하여 어떤 테스트가 실패했는지 확인해 보세요.
각 실패한 작업에서 무슨 일이 있었나요? 실패한 각 작업을 선택하세요. 출력을 스캔하여 실패, 오류 및 빨간색으로 표시된 행에 대한 언급을 찾아보세요. 리뷰 코멘트를 작성할 때, 저자가 무엇을 고쳐야 하는지, 그리고 어떻게 해야 하는지를 이해할 수 있도록 도와줄 수 있어야 합니다.
실패가 변경 사항과 관련되었습니까? 실패가 무관한 것처럼 느껴지면 작업이나 파이프라인을 다시 실행해보는 것을 고려하세요.

재리뷰에 대한 고려사항

가끔 Merge Request 리뷰는 직선적이지 않아서 지정자와 리뷰어 간에 복잡한 교환을 필요로할 때가 있습니다. 작업을 재리뷰하는 경우에는 Merge Request의 커밋 페이지로 이동하여 마지막 리뷰 이후에 추가된 커밋의 내용을 읽어보세요.

이러한 커밋들이 초기 리뷰에서의 관심사를 해결하고 있습니까?

큰 그림에 대해 생각하기

지금까지 심사숙고하고 도움이 될 리뷰를 위한 예비 작업을 마쳤습니다. Merge Request을 대강 훑어보았을 때는 코드 변경 사항의 줄 단위 지식이 완전하지 않았습니다. 하지만 지금은 가능합니다! 리뷰를 작성하기 시작하기 전에 한번 다시 Merge Request을 줄 단위 관점에서 떠나 범위를 다시 생각해보세요. 이제 Merge Request이 무엇을 시도하고 있는지, 그리고 어떻게 시도하고 있는지 알고 있습니다.

Merge Request의 변경 사항이 의도한 범위와 일치하는가요? 그렇지 않으면, 작업을 단순화하거나 여러 Merge Request으로 나눌 필요가 있는지 스스로에게 물어보세요. 자신의 지식 범위와 한계에 대해 솔직하게 되묻으세요.
코드 스멜을 감지했나요? 본질적으로 버그는 아니지만 품질, 유지 관리 또는 보안 문제로 향하는 것이 보이면 주의하세요. 변경 사항에 약간의 예감이 들면 직감을 믿으세요. 코드가 기술적으로 올바르지만 앞으로 문제를 일으킬 약점을 담을 수 있습니다.

가장 좋고 도움이 되는 코드 리뷰는 단순히 줄 단위 수정에 초점을 맞추는 것이 아니라 유지 관리 가능성과 기술 부채와 같은 장기적인 문제들을 고려합니다.

리뷰 완료

피드백을 남기는 시간입니다!

Merge Request을 리뷰하는 것에 익숙해지기 시작하면 첫 번째 의견을 쓰기 전에 생각하는 시간이 얼마나 걸리는지 놀랄지도 모릅니다. 코드베이스에 친숙해질수록 새로운 Merge Request을 더 빨리 이해하게 될 것입니다. 그러나 - 아마도 더 복잡한 리뷰를 하게 될 것입니다.

리뷰 의견 작성

리뷰 시작 기능을 사용하여 보류 중인 의견으로 개인적인 생각을 적을 수 있습니다. 리뷰 끝에 의견을 공개할 때까지 의견을 적을 수 있으므로 시간을 들여 의견을 쓸 수 있습니다. 건설적이고 친절하게 쓰는 것을 기억하세요.

먼저 파일 또는 특정 라인에 첨부해야 하는 의견을 쓰세요:

변경 사항 탭을 선택하세요.
질문을 하거나 피드백을 제공하고 싶은 라인을 찾았다면, 거터에서 이 라인에 의견 추가를 선택하세요. 이렇게 하면 diff 라인이 확장되고 의견 상자가 표시됩니다.
또한 여러 라인을 선택하거나 파일 전체에 의견을 남길 수 있습니다:
텍스트 영역에 첫 번째 의견을 쓰세요. 리뷰 끝에 공개할 의견을 개인적으로 유지하려면 의견 아래에서 리뷰 시작을 선택하세요.
코드 변경이 쉬운 경우나 작성 방법을 보다 나아지게 보여주고 싶을 때 제안을 제공하세요. 코드 변경이 너무 크거나 복잡한 경우 수정 사항을 요청하는 의견을 남기세요.
파일 및 개별 코드 라인에 계속 의견을 달기를 계속하세요. 각 의견 이후 리뷰에 추가를 선택하세요.

작업하는 동안 빠른 조치를 사용하여 리뷰 의견에서 /approve 또는 /assign_reviewer와 같은 작업을 할 수 있습니다. 보류 중인 의견은 요청한 작업을 보여줍니다. 그러나 작업은 리뷰를 제출할 때까지 실행되지 않습니다.

리뷰 요약

파일 및 라인별 피드백을 추가했으므로 이제 리뷰를 요약할 준비가 되었습니다. 마지막으로 전체적으로 생각해보세요.

Merge Request의 개요 페이지로 돌아가세요.
보류 중인 의견을 살펴보세요. 그들은 도움이 되고 사려 깊으며 친절하며, 무엇보다도 _실행 가능_해야 합니다. 이상의 문제를 고치기 위한 분명한 다음 단계를 작성했나요?
톤을 고려하세요. 가르치고 있는지, 토론 중인지, 논의 중인지 확인하세요. 당신의 의견이 목표를 이루고 있는가요? 만약 당신이 작성자라면 다음에 무엇을 해야 하는지 알 것인가요? 좋은 행동을 강화하고 나쁜 행동을 피하도록 작성자에게 유도하세요.
여전히 의견이 맞나요? 큰 Merge Request에서는 일부 의견이 더 이상 유용하지 않거나 답변된 질문이 있을 수 있습니다.
일반화된 피드백 스레드를 시작하세요. 관련 없는 항목이 같은 의견에 묶이지 않도록 스레드를 시작해야 합니다. 몇 가지 가능한 주제:
- 큰 함수를 여러 목적의 작은 단일 함수로 분할하기.
- 의미 있는 변수 이름 사용하기.
- 복잡한 코드를 설명하기 위해 더 많은 주석 추가하기.
- 엣지 케이스 및 오류 확인하기.
요약 의견용 새 스레드를 시작하세요. 작업 디렉터리에서 작업을 하는 경우를 위해 작성자의 사용자 이름을 명시해야 합니다. 명확하게 명시하세요:
- 전반적인 결과는 무엇인가요?
- 리뷰를 마쳤습니까, 아니면 추가 작업이 된 후에 다시 Merge Request을 보고 싶습니까?
리뷰 제출을 선택하여 모든 의견을 공개하고 포함된 빠른 조치를 실행합니다.
- 변경 사항이 좋아 보인다면 승인을 선택하세요.
- 변경 사항이 더 필요하다면 변경 사항 요청을 선택하세요.

Merge Request을 승인하고 리뷰어 디렉터리에 표시된 경우, 이름 옆에 녹색 확인 표시 가 표시됩니다.

정리 작업 수행

피드백을 제공한 후에 정리하세요.

보류 중인 모든 의견이 제출되었는지 확인하세요.
라벨 및 마일스톤을 업데이트하세요.
승인 요구사항을 확인하세요.
- Merge Request의 각 유형(백엔드, 프론트엔드, 문서)이 올바른 사람에 의해 검토되었는지 확인하세요.
- 추가 리뷰가 필요한 경우 다음 리뷰어의 사용자 이름을 언급하고 리뷰어로 추가하세요.
Merge 위젯을 확인하세요.
- 해결할 수 있는 블로킹 사항을 처리하고 해결할 수 없는 것은 사용자를 할당하세요.
- 리뷰를 위해 필요한 코드 소유자를 추가하세요.
Merge Request을 Merge할 준비가 되었습니까? Merge Request이 완전히 리뷰되고 승인되었는지 확인하세요. 그 후 유지자에게 할당하세요!