지속가능한 SW 개발을 위한 코드 리뷰 :: 4월 우아한테크세미나

0. 코드 리뷰가 필요한 이유

비즈니스에서 빠른 혁신을 위하다 보니 개발 조직의 생산성이 중요해졌다.
또한, 유지보수에 더 많은 시간을 할애하기 때문에 재생산이 중요하다.

코드리뷰를 통해 더 나은 코드 개선 뿐만 아니라 지식 공유에 기여할 수 있다. 서로 공유하며 리뷰 과정에서 지식을 얻을 수 있다는 점(하드 스킬, 소프트 스킬), 팀 내에서의 공유 및 팀 간 결속을 단단하게 하여 팀워크를 향상시킬 수 있다는 점, 개발 문화 개선에 기여할 수 있다.

하지만, 코드 리뷰에 대해 어렵다고 생각하는 사람이 많다. (나부터가 진입장벽이 높다고 느낀다.)

생각을 말이 아니라, 텍스트로 전달해야 하기 때문에 오해할 수 있는 위험 가능성이 존재

👤 저자(Author) code 작성, 변경된 부분에 대해 Pull Request를 만들어서 reviwer 에게 줌. review 요청 -> 👤 reviewer code 읽은 후 글로써 feedback, merge 가능한지 결정

그렇다면 어떻게 코드 리뷰를 하면 좋을까 ?

1. 태도

• 잘한 것, 아쉬운 것을 공유하기 → 자신의 지식과 경험을 나누자
• 피드백을 조심스럽게 표현
• 경쟁을 유발하는 것이 아닌, 팀의 생산성을 높이자
• 잘못된 부분에만 집중하는 것이 아니라 좋은 변경 !
• 제안하는 변경 / 변경의 이유

2. 방법

(1) 효율적인 PR 방법

1) 지루한 작업은 컴퓨터로 처리
build, test, merge complete 등 기계가 잘하는 것은 미리 컴퓨터로 검사한 후 로직에 집중할 수 있도록 리뷰 진행)

 

2) 스타일 가이드를 통해 스타일 논쟁 해소 (약속된 code formatting)
좋은 스타일 가이드 있다면 참고, 혹은 팀 내에서 점진적으로 만들기 -> 중요한 것은 서로 합의를 하는 것, 이 부분에서 너무 힘 빼지 말기

 

3) PR 올릴 때 주석 달기
PR을 저자(Author)가 먼저 읽어보고 -> 리뷰어들을 위한 설명을 comment로 남기자

 

4) Formatting Tool
약속하지 않은 대로 들여쓰기를 하거나, 공백이 있는 경우에는 코드리뷰가 어려움.
이런 경우는 별도의 commit/PR로분리
feedback을 원하는 곳에 comment 남기기

5) 모두를 포함하기
많은 사람들이 볼수록 버그를 더 잘 찾아낼 수 있음.
많은 사람들이 본다는 것을 알면 더 잘할려고 하는 경향이 있음.

• 혼자 코드 리뷰할 경우
  의미있는 커밋으로 분리 (잘게 나누기) for 미래의 나

ex ) 이 클래스를 2개로 분리해야합니다. → 지금 이 클래스에는 파일 다운로드, 파싱 이렇게 2가지 책임을 가지고 있습니다. why 다운로더와 파서 2개의 클래스로 분리하여 SRP를 준수하는 것이 어떨까요? how

(2) 효율적인 리뷰 방법

1) 리뷰는 받은 즉시 시작
코드를 읽고 피드백을 줄 때는 시간을 가지고 진행해도 되지만, 저자(Author)는 review가 종료될 때까지 대기하기 때문에 시작을 바로 하기

 

2) Pull Request VS Pair Programmng
성향에 따라 선택

- 추가적으로 보면 좋을 것 같은 사이트

Latency vs Throughput - Understanding the Difference & Meaning

3) 고수준 시작 -> 저수준으로 내려가기
하나의 라운드에서 많은 의견을 남기면 저자가 당황할 수 있다.
초기 라운드에서 고수준(버그, 장애, 성능, 보안, Extract Method, Composed Method, Invert-if(복잡도) 등
이후 저수준 이슈 처리 (변수명 변경, 주석을 명확하게 하는 등)

 

4) 리뷰 범위 존중
PR에 포함되지 않은 부분은 리뷰 범위가 아니다.
단, PR이 둘러싼 코드에 영향을 미치는 경우에는 가능

 

5) 태그활용
[Nit] - 고치면 좋지만, 아니어도 그만
null 대신 Optional을 쓰면 어떨까요?

(3) 코드 리뷰를 잘하기 위해 필요한 기술들

1) 리팩토링(Refactoring)
리팩토링 이란 이미 작성한 소스 코드에서 구현된 일련의 행위들을 변경업싱, 코드의 가독성과 유지보수성을 높이기 위해 내부 구조를 변경하는 것 // 성능 최적화와는 다른 문제

리팩토링 기술(Rename Method, Extract Method 등)을 사용하는 것을 탐색적 리팩토링(Exploratory Refactoring) 부른다.

코드를 읽은 즉시 나의 해설을 표시할 수 있어 적극적으로 리팩토링을 할 수 있게 만든다.

리팩토링이 잘 수행 되었다면 - 코드 위치 파악, 코드 수정, 기능 테스트 을 쉽게 이행 가능

- 참고 도서 - 리팩토링(한빛미디어-javascript)

리팩터링 - 교보문고

2) TDD(Test-Driven Development, 테스트 주도 개발)와 연결된 리팩토링
- Classic(상태기반) and London(interaction 기반)

Unit Testing Principles, Practices, and Patterns

- Outside in -> Inside Out 

3) Clean Code

클린코더스 강좌

Clean Coders : Level up your code.

4) Legacy Code(test가 불가능하거나, 기능이 정상적이지 않거나 가독성이 떨어지는 코드) 다루기
의존성을 깨서 테스트를 쉽게 만드는 법, 테스트 추가 등

 

위 영상을 보고 강의 내용을 개인적으로 정리한 내용입니다.