41. 새 멤버들의 공통된 리뷰 후기
• 초기의 리뷰는 스트레스였다 (특히 코드 스타일)
• 코드 학습 효과가 좋았다
• 시간이 지나니 코드 스타일에 익숙해지더라
42. 생산되는 코드만큼 리뷰 대상도 늘어남
• 멤버가 늘어나니 생산되는 코드량도 늘어남
• 모든 코드를 보기엔 시간이 부족함
• 모든 팀원이 리뷰하길 기다릴 수 없음
43. 리뷰 팀을 구분
• 팀을 두 개로 나눠 리뷰를 진행하기로 함
• 필요하다면 별도의 리뷰어 지정
• 이제는 리뷰하지 못하고 머지되는 코드들도 많음
44. 여전히 리뷰는 지연됨
• 일정에 쫓길수록, 피처 작업 때문에 리뷰가 밀림
• 테스트 날짜가 다가오지 않으면 리뷰하지 않음
• 바쁜 한 사람이 리뷰하지 못해 머지되지 않음
45. 테스트 직전 리뷰가 몰림
• 작업은 일주일 전에 했는데, 리뷰 피드백은 이제
• 버그 수정도 바쁜데 리뷰 피드백까지 해야함
• 컨텍스트 전환 비용이 큼
46. 리뷰 데이 도입
• 매주 정해진 요일을 리뷰 데이로 선정
• 최우선으로 쌓여있는 PR의 리뷰 진행
47. 리뷰 데이의 효과는 미미
• 처음 몇 주까지는 잘 지켜지는 것 같았음
• 본인 PR이 많으면 피드백하느라 리뷰 집중 어려움
• ‘바쁜 한 사람’ 이슈는 해결되지 않음
• 바빠질수록 리뷰는 우선순위가 떨어짐
48. 리뷰 마스터 제도 도입
• 주기적으로 리뷰를 독려하고 머지하는 역할
• 한 주 또는 특정 주기로 PR을 머지하는 책임
• 개인 판단 하에 머지 가능한 것은 빠르게 머지
49. 리뷰 마스터는 성공적
• 개인에게 할당된 책임 때문에 잘 동작함
• 애매한 경우 결정권이 있어 의사결정에 빠름
• 바쁜 한 사람 이슈 해결
50. 여러 사람이 담당하는 피처의 리뷰
• 한 피처를 여러 명이 함께 작업하는 경우
• 작업 범위가 겹쳐 develop으로 PR 애매함
• 피처 단위가 커서 한 번에 리뷰하기엔 부담스러움
51. 메인 피처 브랜치로 PR하도록 함
• 피처의 메인 브랜치인 feature/A를 따고
• 하위 피처를 feature/A-1, feature/A-2로 작업
• 작업 후, feature/A-1 > feature/A 로 PR
52. 2번에 걸쳐 리뷰함
• 상위 피처 브랜치로의 1차 리뷰는 담당자끼리만
• 1차 리뷰는 큼직한 구조나 로직에 대해 러프하게
• develop 브랜치로의 2차 리뷰는 모두가 참여
53. 2차 리뷰의 효과
• 구조 변경에 대한 피드백이 1차 리뷰에서 가능
• 테스트 직전에 큰 변경이 적어짐
• 두 번째 리뷰부턴 확실히 속도가 빠름
54. 서비스 운영 모드
• 오픈 전엔 이터레이션 별로 태스크를 묶어 배포
• 오픈 후 운영 모드로 전환
• 계획보단 실행에 포커스
55. 짧아진 배포 주기
• 구현되는 피처는 가능한 빠르게 배포하기로 함
• 배포 주기: 0.5~3일
• 리뷰 마스터 제도가 자연스럽게 사라짐
56. 리뷰 규칙을 간소화
• 간단한 피처는 한 사람이 바로 머지 가능
• 최소 멤버 N명이 동의하면 바로 머지 가능
• 개발 완료되면 최대한 빠르게 리뷰/머지 후 배포
57. 리뷰가 지연되는 PR이 발생 (피처 원인)
• 배포가 잦다보니 배포 건 위주로만 리뷰하게 됨
• 배포 우선순위가 낮은 피처
• 테스트 기간이 많이 요구되는 피처
58. 리뷰가 지연되는 PR이 발생 (담당자 원인)
• 여러 피처가 섞여 크기가 커진 PR
• 작성자의 피드백이 늦은 PR
• 난이도가 높거나, 한 명이 주도하는 코드
59. 오래된 리뷰는 빨리 머지
• 오래된 리뷰는 빨리 머지하자는 분위기가 형성됨
• 오래된 경우 자세한 리뷰보단 빠른 머지가 낫다
• 배포 비용도 적고, 배포 주기도 짧기 때문
60. 잦은 배포에 대한 피로감
• 매일 배포에 멤버들이 지침
• 배포 비용이 적긴 하지만, 리뷰 + 테스트 필요
• 피처 작업, 배포 준비 간의 컨텍스트 비용 큼
61. 주간 배포 방식으로 변경
• 한 주에 한 번만 배포하는 방식으로 변경
• 배포 건에 따라 화/수/목 중 선택
• 전 주 금요일까지 리뷰가 완료된 건만 배포
62. 이제 더 이상 리뷰는 병목이 아님
• 미리보기 서버로 피처 미리 공유
• 배포 일정을 컨트롤할 수 있음
• 팀원의 리뷰 속도가 빨라짐
63. 2년 동안의 개선
예외적인 상황이 발생됨
컨벤션에 대한 리뷰가 대부분
PR 규모가 커서 리뷰하기 어려움
바쁠수록 리뷰를 미루게 됨
리뷰시간이 예상보다 오래 걸림
리뷰가 병목이 됨
기획/디자인 직군의 불만
통합 테스트 때 스펙 변경이 발생함
서로에 대한 불만
리뷰 병목이 폐해
프로젝트 멤버가 늘어남
생산되는 코드만큼 리뷰 대상도 늘어남
여전히 리뷰는 지연됨
테스트 직전 리뷰가 몰림
사이즈가 큰 피처는 리뷰하기 어려움
짧아진 배포 주기
리뷰가 지연되는 PR이 발생
잦은 배포에 대한 피로감
리뷰 없이 머지할 수 없도록 제한
pre-commit 깃훅에서 린트 수행
오프라인과 온라인 리뷰를 병행
PR과 커밋 단위에 대한 합의
브랜치 미리보기 서버를 구성함
우리 팀은 코드 리뷰를 하는 팀
리뷰 팀을 구분
리뷰 데이 도입
리뷰 마스터 제도 도입
메인 피처 브랜치로 PR하도록 함
2번에 걸처 리뷰함
리뷰 규칙을 간소화
오래된 리뷰는 빨리 머지
주간 배포 방식으로 변경