Intro
코드 리뷰를 받다가, 들은 피드백이다.
이게 "진짜 중복인지, 가짜 중복인지 생각해봐야해요.."
처음에는 가짜 중복? 중복이 가짜도 있나? 라는 생각이 들었다.
하지만, 리뷰어 분이 "중복된 사항들이 각각 다르게 변화할 수 있는 가능성이 존재하는지에 대해서 생각해봐야한다"라고 말씀해주셨다.
그때 머리를 띵 맞은 기분이었다. 나는 사실 현재 코드가 같다면, 다 묶는게 유지 보수에 더 좋을 것이라고 생각했다.
하지만, 이 이야기를 듣고 다시 생각해보면, 코드를 묶는 것보다 분리해놓는게 유지보수에 더 나은 선택일지도 모른다. 왜냐하면 분리 -> 묶음은 쉽지만, 묶음 -> 분리는 어렵기 때문이다...
이게 지금은 진짜 중복처럼 보일 수 있지만, 추후에 도메인 변경 혹은 정책 변경에 따라서 분리되어야하는 것들이 될 수도 있기 때문이다.
그래서 이 피드백을 듣고는 항상 이게 진짜 진짜 중복인지 고민해보고, 완벽하게 일치하는 것이 아니라면, 웬만하면 분리해두려고 한다..
진짜 중복 vs 가짜 중복
진짜 중복
말 그대로 진짜 중복이다. 한 곳의 코드를 고친다면, 다른 코드도 무조건 고쳐야하는 것이다.
예를 들어서,
interface Soomin {
name: string;
age: number;
}interface Sooyeon {
name: string;
age: number;
}둘 다 같은 특정 서비스의 회원이라면 Soomin과 Sooyeon은 사람이라는 공통적인 속성으로 묶일 수 있고, 개별적으로 다른 속성을 가질 가능성이 없다. (왜냐하면, 회원별로 구분하여 type을 다르게 사용할 가능성은 없다.)
그렇기 때문에, 만약에 gender라는 속성이 추가될 경우, 한 가지에만 추가되지 않고 Soomin, Sooyeon 모두에게 추가되어야한다.
다시 말해, 한 군데를 바꾸면 반드시 다른 곳에도 복사 붙여넣기가 필요한 경우이다.
가짜 중복
그렇다면, 가짜 중복은 어떤 경우가 있을까?
function isLengthOverMax(length: number) {
if (length > 100) {
return true
}
return false
}이러한 함수가 문자와 이메일의 길이를 측정하는데 사용되고 있다고 생각해보자.
당시에는 서비스의 정책 기준으로 문자와 이메일의 100자 이하이었기 때문에 해당 함수를 만들었을 것이다.
하지만, 해당 정책은 충분히 변경의 여지가 있다. 예를 들어, 이메일은 140자로 변경되고 문자는 오히려 90자로 줄었다고 해보자.
중복처럼 보였던 것이 시간이 지나며, 정책 / 도메인 등이 변경되면서 변경되었다. 이런 것을 가짜 중복이라고 한다.
이를 어떻게 해결할 수 있을까?
관심사가 다르다면, 분리하자.
방금의 예시처럼 변경 가능성이 존재하는 것은 굳이 묶어놓을 필요가 없다.
