목적

저는 공유와 히스토리를 가장 큰 목적으로 두고 있고, 서로의 도메인 지식을 향상시키는 것이 가장 큰 의도입니다. PR 의 명시된 티켓과 설명을 통해 해당 기능의 목적이 무엇인지? 어떠한 니즈를 통해 추가되었는지에 대한 도메인 측면을 먼저 파악합니다. 그리고 적용된 코드가 요구사항을 잘 의도하고 있는지를 고민하고 피드백을 남깁니다. 비중이 크게 두고 있지는 않지만 필요하다면, 코드 스타일 측면에서도 피드백을 남기고 있습니다.

주의사항

구성원들이 코드 리뷰를 해주지 않는 것을 그 사람의 문제라고 판단하면 안됩니다. 어떤 이유로 코드 리뷰를 안 하는 것인지? 어떤 것들이 불편한지? 그러한 것들을 시스템으로 하나하나씩 개선하고 해소해야합니다.

팁 1 - PR 을 위한 결과물 상시 배포

효과적인 코드 리뷰를 위해서는 리뷰어들이 PR 의 내용과 결과물을 가장 쉽게 확인할 수 있어야합니다. 내용은 티켓이 잘 관리되어있어야하고, 결과물은 상시 PR 을 위한 환경에 배포되어있어야합니다.

각 작업자는 작업을 마치고 PR 을 생성하기 전에 DEV 환경에 작업물을 배포해야합니다. 작업물이 배포된 환경을 통해 리뷰어들이 PR 에 관련된 기능들을 손쉽게 확인할 수 있습니다.

merged_dev 라는 명칭으로 약속된 더미 브랜치가 존재합니다. develop 브랜치를 기준으로 각자 현재 진행중인 작업물들을 위한 브랜치로 활용됩니다. 해당 브랜치는 push 되면 자동으로 DEV 환경에 배포됩니다.

작업자들은 본인의 작업이 끝나면 작업된 브랜치와는 별개로 merged_dev 에 한번더 푸시를 보장해야합니다.

%% 코드 리뷰
graph LR
%% __START
    Coworker1 --> feature/a
    feature/a --> merged_dev
    Coworker2 --> feature/b
    feature/b --> merged_dev
    Coworker3 --> feature/c
    feature/c --> merged_dev
    merged_dev --> Github
    Github -.->|dispatch| GithubActions
    GithubActions -->|deploy| Application

    subgraph "DummyBranch"
        merged_dev
    end

    subgraph "Branch"
        develop
        main
        feature/a
        feature/b
        feature/c
    end

    subgraph "CI/CD"
        GithubActions
        Github
    end
%% __END

팁 2 - 짝 리뷰

특정 기간 or 특정 작업의 경우에는 짝을 지어 코드 리뷰를 진행합니다. 짝은 조금 더 고도화된 리뷰를 진행하게 됩니다. 서로의 승인이 필수적으로 진행되어야하는 규칙을 가지고 있습니다.

팁 3 - 시스템 고도화

방치되고 있는 PR, 현재 PR 리스트 등을 알림 기능을 통해 알려줄 수 있습니다.