뱅크샐러드 블로그 - 코드리뷰에 대해

뱅크셀러드의 코드 리뷰 in 뱅크샐러드 개발 문화 를 읽고 쓰는 글입니다.

들어가기 앞서

• 코드 리뷰는 그 회사의 개발 문화를 이해할 수 있는 힌트가 되기도 합니다.
• 비동기 커뮤니케이션은 요청에 실시간적인 응답을 요구하지 않는 커뮤니케이션을 말합니다.
  • 비동기 커뮤니케이션은 개인의 업무시간을 존중하고, 커뮤니케이션 비용을 줄이기 위해 사용됩니다.

뱅크샐러드의 코드 리뷰

작은 PR 규칙

• 1개의 PR은 1,000 Line을 넘을 수 없다.
• 코드가 길수록 리뷰어의 집중도가 떨어지기 때문에 도입했다.
• 이를 실천하기 위해 또다른 세부 규칙이 생겨났다.
  • PullRequest, Commit의 단위는 최소의 기능 단위로 세분화한다
  • 테스트 코드는 Mock json 이 라인 수의 대부분을 차지하므로 제한을 두지 않는다.

실험 플랫폼

• 뱅크 샐러드는 가설을 발굴하고 실험을 통해 검증하는 과정을 통해 새로운 기능을 출시하고 있다.
• 고객이 사용하는 OS, 앱 버전에 따라 실험군과 대조군을 나눠 작업을 진행했다.

if(유저가 대조군이면){
	return 기존UI
}else if(유저가 실험군이면){
	return 새로운UI

}

작은PR과 실험 플랫폼의 결합

• 뱅크샐러드 2.0작업을 할 때 이렇게 했다.
  • 기존의 정기배포와 함께 2.0개발이 진행되었는데, 정기배포만 주기적으로 main에 merge하고 2.0개발은 완성될 때 한번에 merge하면 엄청난 혼란이 일어날 것이 예상되었다.
  • 하지만 실험 플랫폼의 방법으로 유저에게 기존의 화면을 보여주면서 새로운 기능을 main branch에서 계속 개발하였다. 이 것이 가능한 이유는 작은 PR로 기능을 잘 세분화했기 때문이다.

저 문맥(Low Context) 커뮤니케이션 지향

• 내가 아는 걸 상대도 안다고 가정하지 않고 충분한 설명을 기본으로 합니다.
  • 왜냐하면 미스 커뮤니케이션으로 발생하는 비용을 매우 비싸게 인식하고 있기 때문입니다.
• 코드 리뷰 가정에서도 리뷰 요청자가 충분히 이해할 수 있도록 PR이 Open되기까지 참고했던 기획서, 테크 스펙, Figma 등의 링크를 충분히 제공합니다.

코드 리뷰 과정에서 이루어지는 것

• 일관된 아키텍처를 유지하고 있는지에 대한 고민
• 다른 해결 방법에 대한 의견 제시
• 버그가 발생할 수 있는 가능성 제시
• 기술적인 지식과 노하우 공유
• 히스토리 전달

Pn룰을 통해 코멘트의 강조하고 싶은 정도를 표현

• P1: 꼭 반영해 주세요
• P2: 적극적으로 고려해 주세요
• P3: 웬만하면 반영해 주세요
• P4: 반영해도 좋고 넘어가도 좋습니다
• P5: 그냥 사소한 의견입니다

D-n룰을 통해 PR리뷰의 우선순위를 표현

• n일 이내로 리뷰해 주세요
• D-0은 긴급한 수정사항이니 바로 리뷰해 주세요

코딩 스타일

• SwiftFormat을 도입했다.

느낀점

• 유사한 방식의 알고리즘 문제풀이 및 리뷰 스터디를 막 시작한 상황이라 글의 내용이 더 흥미로웠습니다.
• 저는 branch를 나눠서 작업하는 게 무조건 더 좋다라는 생각을 무의식에 가지고 있었나 봅니다. 뱅크샐러드의 2.0작업 사례를 통해 오랫동안 merge되지 않은 코드의 가치 및 위험성에 대해 고민해보게 되었습니다.
• 기존의 것과 새로운 것이 함께 공존하는 실험 플랫폼이 흥미로웠습니다. 하지만 이 경우 독립적인 환경보다는 속도나 안전성 부분이 떨어질 거 같은데 이러한 부분을 어떻게 보완하고 있을 지도 궁금해 졌습니다.
• 어느정도 코딩 스타일에 대한 가이드라인(Swift foramt)이 존재하는 것도 신기했습니다.
  • 확실히 사람마다 코딩 스타일은 다르고, 다른 사람의 코드를 이해하는 건 어려운 일이라는 걸 스터디를 통해 느끼고 있습니다.