본문 바로가기

카테고리 없음

2.코드리뷰 방법론 소개

[오프라인 코드리뷰 방법들]

 - Inspection

  ㄴ 1970년 대초  IBM 의 직원에 의해 정립된 정검/검사의 방법 

  ㄴ 전문적인 팀이 필요함 , 프로세스와 checklist 기반에 따라 문제를 찾음

 

 - Peer Review

   ㄴ 실제 개발팀이 모여서 한다.

   ㄴ 보다 더 자유롭다.

   ㄴ 일주일에 한두번 정도 정기적으로 PLTL 주도하에 진행 

   ㄴ Defect 들은  Jira등으로 담당자 할당 후 해결

   ㄴ 담당자:   Author(자신의 코드 발표) , Moderator (리뷰 주제 설정, Action Item 으로기록) ]

 

- Peer Desk Check

   ㄴ Code commit 이전에 모니터 보면서 서로 짧은 의견 나누는 방식

   ㄴ 가장 쉬움 , 빠르게 쉽게 오류를 찾을 수 있음

   ㄴ Build 여부 , Unit Test 개발 여부, 잘읽히는지, 커밋 내용 확인 등

   ㄴ 다른리뷰와 함께하면 효과가 보충 효과가 좋음

 

- Pass Around 

   ㄴ 개발자가 메일을 통해 리뷰할 내용 등록

   ㄴ 참석자들이 의견전달 ( 메일회신이라서 관심있지 않은 경우 느림 ) 

 

- Pair Programming 

   ㄴ Navigator 가 작업 방향 제시, 코드리뷰 수행 등

 

[온라인 코드리뷰 기법들]

 - Automated Peer code review 

    ㄴ 커밋에 리뷰남기고 커밋자가 메일받으면 다시 수정하고

 - Modern code Review

 

 - Pre Commit Review  

    ㄴ 코드가 파이널 브랜치에 들어가기 전에 코드리뷰를 한다.

    ㄴ 코드리뷰가 강제화 된다.

    ㄴ 고품질의 main 브랜치를 가지게 된다.

    ㄴ 최종 브랜치에 안착 되기까지 오래걸려서,  과정기간 동안에 다른 커밋이 씹히거나 할수 있다.

 

 - Post Commit Review 

    ㄴ 복잡한 요구사항을 여러명이 구현할때 좋음 ( 일단 커밋후 확인 )

    ㄴ 지속적인 코드 변경 사항 반영 가능  

    ㄴ  결함 발견시 롤백시 문제가 생길 수 있음