💡 Facebook 에서는 개발에 가장 중요한 세 가지 요소로 코드리뷰와 코드리뷰, 그리고 코드리뷰를 꼽기도 했습니다.
무엇을 리뷰해야 하는가?
- 성능 개선 개발 : 시간복잡도
- 신규 feature 개발 : 잠재적인 오류에 대한 검출
- 리팩토링 : 테스트 코드나 구조에 대한 물음
- 신규 기술 도입 : 해당 기술의 로직과 그에 대한 물음
- 기타 : 변수명과 같은 코드 컨벤션을 하기도 한다. 전체적인 흐름을 이해하기 위해 실제 빌드를 해서 동작을 시켜보고 이해하기도 합니다.
어떻게 리뷰해야 하는가?
변화를 작게 유지하자
- Cisco 시스템 프로그래밍 팀의 연구에 따르면 300줄에서 400줄 정도의 코드를 60분에서 90분동안 리뷰하면 70~90%의 결함을 발견할 수 있다고 합니다.
리뷰는 자주, 짧은 세션으로 진행하자
- 코드 리뷰는 적절한 양을, 천천히, 정해진 시간 동안에 진행할 때 가장 효과적인 결과가 나옵니다.
- 리뷰를하면서 코드가 500줄을 넘어가면 참석한 리뷰어는 결함을 찾아낼 수 있는 능력을 잃어버립니다.
- 결함이 발견되는 비율(inspection rates)는 1시간에 300줄 정도일 때가 좋습니다.
의미있는 PR을 만들어 충분한 정보를 제공하자
- 리뷰어가 코드의 문맥을 빨리 파악할 수 있도록 충분한 정보를 제공하는 것이 중요하다.
- 무슨 이유로 어떻게 코드를 변경했는지, 어떤 위험이나 우려가 발견되었는지에 대한 충분한 정보를 리뷰어에게 제공해야 한다.
- 이런 작업을 할때 GitHub에서 제공하는 이슈와 PR 템플릿을 사용하면 도움이 될것이다.
- 무슨 일을 하려는지 설명하는 스크린 샷을 첨부하는것도 매우 좋은 아이디어
코드 분석 및 코드 스타일 확인을 거치자
- 우리의 눈을 중요한 비지니스 로직과 알고리즘 확인을 위해 아껴두고, 정적 코드 분석과 코딩 스타일 확인은 SonarQube나 ESLint와 같은 툴에게 맡기자
코드 리뷰에서 가장 중요한 부분 중의 하나는 개발자들의 성장과 노력에 대해 보상하는 것이다. 따라서 최대한 많이 그들을 칭찬해주도록 노력해야한다.
마지막으로 코드를 제대로 이해할 수 없다면 적절한 리뷰가 될 수 없다.
- 진행되고 있는 논의가 지지부진한 것 같다면, 좀 더 효과적으로 리뷰할 수 있는 사람을 찾아서 논의가 진전될 수 있도록 합니다.
유익하다고 느꼈던 리뷰들
- 미리 발견하는 버그
- 기존 코드의 히스토리
- 삽질 회피 코드의 공유
- 더 나은 로직의 제안
- 더 나은 변수명 제안
조금은 불필요한 논쟁이라고 생각했던 리뷰들
- 취향의 차이 (if vs switch)
- 바꾸기도 뭐하고 안 바꾸기도 뭐한 애매한 수준의 변수명 제안
- 아주 미묘한 성능 개선 제안
- 너무 먼 미래에 대한 방어 코드
코드를 잘 봐주기 위한 실력을 늘리기 위해서는 어떻게 해야하는가?
- 도메인 이해력, 언어 이해력
- 이해하기 어려운 비지니스 로직에 대한 코멘트 안내 등 남이 이해할 수 있는 방식을 제안
- PR을 날리는쪽에서 보기 쉽게 만들어주어야 한다.
- 내가 모르는 부분이면 코드를 받아서 돌린다.
- "내 코드를 사람들이 더 잘 봐주면 좋겠다."에서 접근
- 라벨링을 잘 활용하자
- PR이 크면 다 같이 모여서 context 파악
참고
- https://tosslab.github.io/codereview/2015/12/18/%EC%BD%94%EB%93%9C%EB%A6%AC%EB%B7%B0-%EC%9D%B4%EB%A0%87%EA%B2%8C-%ED%95%98%EA%B3%A0-%EC%9E%88%EB%8B%A4.html
- https://engineering.linecorp.com/ko/blog/effective-codereview/
- https://tech.kakao.com/2016/02/04/code-review/
- https://velog.io/@zetlos/%EC%86%8C%EC%8A%A4%EC%BD%94%EB%93%9C-%EB%A6%AC%EB%B7%B0%EC%97%90-%EB%8C%80%ED%95%9C-%EC%A7%A7%EC%9D%80-%EC%9D%B4%EC%95%BC%EA%B8%B0
안드로이드 개발자 입니다