코드 품질 개선 기법 25편: 요컨대... 무슨 말이죠?

이 글은 2024년 5월 16일에 일본어로 먼저 발행된 기사를 번역한 글입니다.

LY Corporation은 높은 개발 생산성을 유지하기 위해 코드 품질 및 개발 문화 개선에 힘쓰고 있습니다. 이를 위해 다양한 노력을 하고 있는데요. 그중 하나가 Review Committee 활동입니다.

Review Committee에서는 머지된 코드를 다시 리뷰해 리뷰어와 작성자에게 피드백을 주고, 리뷰하면서 얻은 지식과 인사이트를 Weekly Report라는 이름으로 매주 공유하고 있습니다. 이 Weekly Report 중 일반적으로 널리 적용할 수 있는 주제를 골라 블로그에 코드 품질 개선 기법 시리즈를 연재하고 있습니다.

이번에 블로그로 공유할 Weekly Report의 제목은 '요컨대... 무슨 말이죠?'입니다.

요컨대... 무슨 말이죠?

어떤 개발자가 다음과 같은 클래스를 만들고 코드 리뷰를 요청했다고 가정해 봅시다.

data class UserModel( val userId: Int, val accountName: String, val ... var onlineStatus: OnlineStatus, var statusMessage: String )

위 코드에 대해 리뷰어는 다음과 같은 코멘트를 남겼습니다.

data 클래스에는 copy 함수가 있습니다. 속성 값을 변경하고 싶을 경우 해당 속성을 직접 수정하는 대신 해당 함수를 호출해서 별도의 인스턴스를 생성할 수 있습니다.

UserModel.onlineStatus와 statusMessage에 대해 copy를 사용하지 않고 var로 재할당이 가능하도록 한 것은 이 값들이 자주 업데이트되고 동일한 객체를 통해 업데이트된 상태를 공유하기 위한 것이라고 예상할 수 있습니다.

하지만 일반적으로 가변 객체를 공유하면 의도하지 않은 시점에 속성이 변경돼 버그가 발생하기 쉽습니다. 상태를 업데이트할 때마다 새 인스턴스를 생성하면 더 견고한 코드를 만들 수 있습니다.

결론적으로 이 클래스의 모든 속성은 val로 선언하는 것이 좋다고 생각합니다. 인스턴스를 복사하는 비용이 걱정될 수도 있지만 UserModel의 상태가 업데이트되는 빈도는 높지 않을 것입니다. 또한 onlineStatus와 statusMessage만 업데이트되는 경우가 많을 것 같다는 점에서 이들을 다른 안정적인 속성과 분리하는 것이 좋을 수도 있습니다. 예를 들어 다음과 같이 하는 것은 어떨까요?

data class UserModel( val userId: Int, val accountName: String, val ... ) class UserStatus( val userModel: UserModel, val onlineStatus: OnlineStatus, val statusMessage: String )

위와 같은 리뷰 코멘트는 어떻게 개선할 수 있을까요?

요컨대...

리뷰 코멘트를 작성할 때는 제안이나 요청 사항을 먼저 쓰고 그 이유는 뒤에 덧붙이는 것이 좋습니다. 이 경우 코멘트를 개선하면 다음과 같습니다.

UserModel의 값 업데이트 빈도에 따라 클래스를 분리하고 모든 속성을 val로 만드세요.

data class UserModel( val userId: Int, val accountName: String, val ... ) class UserStatus( val userModel: UserModel, val onlineStatus: OnlineStatus, val statusMessage: String )

이 변경은 다음 두 가지 측면에 기반합니다.

1. 객체의 불변성: 가변 객체를 공유하기보다는 상태 업데이트 때마다 불변 객체를 일회용으로 사용하는 것이 의도하지 않은 시점에 속성이 변경되어 발생하는 버그를 방지하기 쉽습니다. 또한 data class에서 var 속성을 정의하면 copy와 쓰임을 구분하는데 혼란을 초래할 수 있으므로 피하는 것이 좋습니다(자세한 내용은 https://… 참조).

2. 값의 라이프사이클: onlineStatus와 statusMessage는 다른 속성보다 더 자주 업데이트됩니다. 업데이트 빈도가 높은 속성과 낮은 속성을 분리하면 잘못된 업데이트를 방지하기 쉽습니다.

제안이나 요청 사항을 먼저 제시하면 리뷰 요청자는 코멘트의 주요 포인트를 먼저 이해한 뒤 이유의 타당성을 검증할 수 있습니다. 이렇게 하면 다시 읽어볼 필요가 줄어듭니다. 개선된 코멘트는 ‘이유’ 설명에도 더 신경을 썼습니다. 먼저 항목이 몇 개인지 제시하고 각 항목에 제목을 붙여 구조를 이해하기 쉽게 만들었습니다.

참고로 이 시리즈에서는 중요한 부분을 의도적으로 마지막에 쓰는 경우도 있습니다. 그 이유는 '빠른 이해'보다 '생각해 보도록 만드는 것'을 더 중요하게 여기기 때문입니다. ;)

---

한 줄 요약: 리뷰 코멘트를 작성할 때는 제안이나 요청 사항을 먼저 쓰고 그 이유는 뒤에 덧붙인다.

키워드: code review, review comment, explanation order