[Chapter 14] 269p int price와 class Price 그리고 나무꾼 우화

[Irisation23]

269p 발췌

• Price 클래스

class Price {
  private final int amount;
  //생략
  int add(final Price other) {
    return amount + other.amount;
  }
}

• Price add()의 리턴 값인 int 자료형 price

int price = productPrice.add(otherPrice);

• int 값을 리턴하기 때문에 값이 어떤 의미를 갖는지 알기 어려워 Price 클래스로 리턴

Pirce add(final Price other) {
  final int added = amount + other;
  return new Price(added);
}

책에서 설명하는 바는 다음과 같습니다.

• int로 리턴되어 역할이 모호하다.
• class로 리턴되게 하여 타입을 명시하여 모호성을 없앤다.

이는 이상적인 리팩터링이라고 볼 수 있다고 생각합니다.

그러나 저희는 이상적인 리팩터링을 하게 될 가능성이 낮다고 생각됩니다.
왜냐하면 실무에서 작성된 코드 수만줄은 다음의 int 자료형을 그대로 받아 사용하고 있을 것이기 때문입니다.
예를 들면 나무꾼 우화처럼 시간에 쫓겨 일단 프로그램이 문제없이 돌아가기 위해서 위와 같이 작성된 int add()를 사용할 확률이 높습니다.
따라서 이상적인 리팩터링을 하기에는 시간에 쫓겨 어려울 수 있다고 생각됩니다.

질문

• 만약 위와 같은 상황 수만줄의 코드에서 int add()를 사용하고 있고, 이를 리팩터링을 해야함을 알지만 시간에 쫓겨 건들일 수 없다면 여러분은 어떤 선택을 할 것인가요?

1. 팀원과 공유하여 문제점이 있는 코드임을 알린다.(리팩터링 한다.)
2. 그냥 넘어간다.(리팩터링 하지 않는다.)

[firewoody237]

책에서 얘기하는 Price는 값 객체로 보이는데요,
값객체는 내부에 int와 같은 값들을 Wrapping하고 있기 때문에 연관된 모든 부분에 적용할 필요는 없고, 국소적인 부분부터 적용해 나갈 수 있을 것 같습니다.
Price� 제약조건등이 있는 도메인 영역이라면, 고치는게 장기적으로 좋을 것 같네요.

그 외에 애플리케이션 서비스 등에서 뱉어내는 값들이라면, 긁어 부스럼을 만들 것 같진 않습니다!

[corock]

우선 리팩터링을 당장 하든 말든 팀원과 내용은 공유하는 편입니다.
저라면 리팩터링 대상의 견적을 보고 side effect 에 대해 책임질 수 있는 정도겠다 싶으면 진행할 것 같아요.
만약 그렇지 않다면 다음을 기약하며 넘어갑니다(하지만 보통 다음은 없다고 많이들 말씀하시더라구요 ㅎㅎ).