[TIL] 240207 - 코드 리뷰 in 뱅크샐러드

코드 리뷰 in 뱅크샐러드 개발 문화 | 뱅크샐러드

코드 리뷰

• 개발자가 작성한 코드를 다른 사람들이 검토하고 피드백을 전달하며, 다시 작성자가 반영하는 과정
• 서비스의 기술적인 구현 부분에 대해 공유 및 습득 가능
• 일관된 아키텍처를 유지하며 문제를 해결할 수 있는 새로운 관점을 발견
• 잠재적인 장애, 버그를 배포전에 발견하여 전반적인 서비스 운영 비용을 절약 가능
• 코드의 품질, 서비스의 품질을 높이려는 목적을 가짐

비동기 커뮤니케이션

• 요청에 실시간으로 응답하거나, 응답을 요구하지 않는 커뮤니케이션
• 업무 진행에 필요한 대부분의 커뮤니케이션은 Jira, Slack, 메일 등을 통해 비동기적으로 진행
• 개인의 업무 시간을 존중하는 문화 덕분에 개발자들은 개인이 업무에 집중할 수 있는 시간에 방해받지 않고 업무에 몰두
• GitHub Pull Request(이하 PR)를 코드 리뷰의 툴로 사용하는 이유도 비동기적으로 코드 리뷰 할 수 있는 환경을 만들 수 있기 때문입니다.
  • 비동기적이라는 장점 외에도 코드 리뷰 프로세스가 잘 구현
  • PR을 통해 리뷰어의 Approve(승인), Comment(피드백 및 토론), Request Changes(수정 요청) 표현을 명확 가능
  • 리뷰 결과에 따라 메인 브랜치에 merge 할 수 있는 자격이 주어지거나, merge를 block 할 수 있는 기능을 제공
• 코드의 길이가 길어질수록 리뷰어의 집중도는 떨어지며, 코드를 이해하는 시간이 길어지고, 리뷰는 목표한 일정에 완료되지 못하고, 병목이 되기 시작함
  • 모든 PR은 200 ~ 300줄 내외가 되고 1~2일 이내에 리뷰를 완료하여 리뷰의 병목을 해소
  • 개발되는 코드의 양(= PR의 양) 도 증가했지만 ‘작은 PR 규칙’ 아래 병목 없는 성장

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

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

코딩 스타일 ( Indent, Convention )

• “자동화 할 수 있는 부분은 자동화하여 사람의 리소스를 아끼자”
• 코딩 스타일은 가독성 관점에서 포기할 수 없는 부분
• 코드 리뷰 단계에서 Blocker가 될 만큼 중요하지는 않으며 자동으로 코딩 스타일을 맞춰지는 프로세스를 맞추어 감

유닛 테스트

• 안정적인 서비스 운영을 위해 테스트 코드 작성을 높은 수준으로 권장하고 있으며, 테스트 케이스를 통해 코드의 변경점으로 인해 발생할 수 있는 사이드 이펙트를 제거