tidy first 12장 '도우미 호출' 를 읽고

과도한 메서드 추출

메서드 추출을 과도하게 사용하면, 코드가 잘게 나뉘고 참조해 들어가는 메서드가 많아지기 때문에 오히려 코드를 이해하기 어려워질 수 있습니다. 지난번 인간이 단기적으로 기억할 수 있는 청크(chunk)가 4개 정도인 것으로 미루어 보았을 때, 과도한 메서드 추출은 지양해야 겠습니다. 그래서 적절한 수준에서 메서드를 추출해야 하고, 추상화 수준이 일관되게 유지되도록 하는 것이 중요하다고 생각했습니다.

 

추출한 메서드 이름 짓기

메서드를 추출할 때, 그 메서드의 이름을 짓는 것도 매우 중요하다고 생각 했습니다. 그 메서드가 '어떻게' 동작하는지가 아닌, '왜 필요한지' 표현할 수 있어야 합니다.

 

예를 들어, 할인 금액을 계산하는 메서드를 추출했다고 가정 해보겠습니다.

// '어떻게' 관점에서 지은 메서드 이름
private double subtractDiscountFromTotal(double total, double discount) {
    return total - discount;
}

이름을 보면 알겠지만, '어떻게 계산하는지' 를 표현하는 이름 입니다.

 

다음은 '왜 필요한지' 관점에서 메서드 이름을 지어본 예시입니다.

// '왜 필요한지' 관점에서 지은 메서드 이름
private double applyDiscount(double total, double discount) {
    return total - discount;
}

이름에서 알 수 있듯, 할인 금액이 '어떻게' 계산 되는지가 아닌 '할인을 적용한다' 는 존재 이유를 표현하고 있습니다.

 

더 나아가 이것을 '변경' 관점에서도 생각해볼 수 있습니다.

'왜 필요한지' 의 관점에서 이름을 지으면, 메서드의 '목적'을 나타내기 때문에 내부 구현이 바뀌어도 이름을 유지할 수 있지만, '어떻게' 관점에서 지은 이름은 계산 방법이 바뀌면 이름도 같이 바뀌어야 합니다. 그렇기 때문에 유지 보수 관점에서 보다 유연한 메서드 이름을 지을 수 있습니다.

 

따라서 이름만 보고도 그 메서드가 어떤 목적을 위해 존재하는지 알 수 있도록 이름을 짓는 것이 중요하다고 생각합니다.

 

재사용 여부와 관계없이 도우미 추출의 가치는 있다

메서드를 추출하는 이유 중 하나는 재사용성을 높이기 위함도 있지만, 재사용 하지 않더라도 도우미 메서드를 추출하는 것 자체만으로 가독성이 좋아질 수 있습니다. 그래서 비록 한 번만 사용되더라도, 도우미를 추출하는 것은 가치가 있다고 생각 했습니다. 또한 메서드 추출로 책임을 명확히 분리했기 때문에, 뒷통수(?) 맞는 일을 방지할 수 있습니다.

 

도우미 메서드를 없애고 바라보면, 보이지 않던 코드 구조를 발견할 수도 있다

가끔은 도우미 메서드를 없애고 전체적인 코드를 다시 바라볼 필요가 있다고 생각했습니다. 특히 습관적으로 추출한 경우, 또는 시간이 지나 추출한 메서드 구현이 복잡해진 경우 유효한 방법이 될 수 있겠습니다. 추출한 메서드를 인라인에 포함 시키는 과정에서 도우미 메서드가 정말 필요했는지 다시 한 번 고민할 수 있습니다. 경우에 따라서는 도우미를 없애는 것이 더 읽기 편할 수도 있고, 보다 응집도 있게 추출 할 메서드를 발견하는 데 도움이 될 수 있겠다고 생각 했습니다.

 

도우미 함수는 결과를 반환하는 것이 좋다

도우미 함수는 가능하면 결과를 반환하도록 작성하는 것이 좋겠다고 생각 했습니다. 참조하고 있는 값을 직접 변경하면 그 값이 어떻게 변경되었는지 추적하기 어렵기 때문입니다. 반환값을 명확하게 처리하는 방식은 코드의 예측 가능성을 높이고, 부작용을 줄이는 데 도움이 된다고 생각합니다.