코드 품질 개선 기법 25편: 요컨대... 무슨 말이죠? (새 탭에서 열림)
효과적인 코드 리뷰를 위해서는 리뷰 코멘트를 작성할 때 결론인 제안이나 요청 사항을 가장 먼저 제시하고, 그에 따른 근거와 이유는 뒤에 덧붙이는 구조를 취해야 합니다. 이러한 방식은 리뷰 요청자가 코멘트의 핵심을 즉각적으로 파악하게 하여 전체적인 리뷰 프로세스의 효율성을 높여줍니다. 명확한 구조로 작성된 코멘트는 불필요한 재독을 줄이고 제안된 의견의 타당성을 더 빠르게 검증할 수 있게 돕습니다.
불명확한 리뷰 코멘트의 예시와 문제점
- 가변 객체 사용의 위험성: Kotlin의
data class에서 속성을var로 선언하면 외부에서 객체의 상태를 직접 변경할 수 있어, 의도치 않은 시점에 데이터가 수정되는 버그를 유발할 수 있습니다. - 불필요한 인스턴스 공유: 상태를 업데이트할 때 새로운 불변 인스턴스를 생성하는 대신 동일한 가변 객체를 공유하면 시스템의 견고함이 떨어집니다.
- 정보 전달의 지연: 제안 사항(모든 속성을
val로 변경하고 클래스를 분리할 것)이 코멘트의 마지막에 위치하면, 작성자는 긴 설명을 다 읽은 후에야 무엇을 고쳐야 하는지 알게 되어 인지적 부담이 커집니다.
제안 사항 우선 방식의 코멘트 구조화
- 핵심 제안 선행: 코멘트의 첫머리에 "데이터 업데이트 빈도에 따라 클래스를 분리하고 속성을
val로 선언하세요"와 같이 구체적인 액션을 명시합니다. - 근거의 범주화: 제안 뒤에 붙는 이유는 '객체의 불변성'과 '값의 라이프사이클'처럼 논리적인 항목으로 나누어 설명합니다.
- 가독성 향상 기법: 설명해야 할 항목이 몇 개인지 미리 밝히고(예: "다음 두 가지 측면에 기반합니다"), 각 항목에 제목을 붙여 구조화하면 전달력이 극대화됩니다.
데이터 모델링의 기술적 개선 방향
- 불변성 유지:
data class에서는var대신val을 사용하여copy함수를 통한 예측 가능한 상태 업데이트를 지향해야 합니다. - 라이프사이클에 따른 분리: 사용자 ID와 같이 거의 변하지 않는 속성과, 온라인 상태나 상태 메시지처럼 자주 변하는 속성을 별도의 클래스(예:
UserModel과UserStatus)로 분리하면 잘못된 업데이트를 방지하기 쉬워집니다.
리뷰 코멘트를 작성할 때는 '빠른 이해'를 목표로 결론부터 쓰는 것이 기본입니다. 다만, 상대방이 스스로 답을 찾아보게 하거나 깊은 고민을 유도하고 싶을 때는 의도적으로 중요한 부분을 뒤에 배치하는 전략을 취할 수도 있습니다. 상황에 맞는 적절한 설명 순서가 코드 품질과 팀의 개발 문화를 결정짓는 중요한 요소가 됩니다.