[TIL]20241112 Depth

오늘은 코드에서 자주 언급되는 'Depth'에 대해 개발일지를 작성해보려고 한다. Depth라는 개념을 잘 알지 못했지만, 이번 기회를 통해 학습하면서 더 나은 코드를 작성하기 위한 방법을 고민해보려고 한다.

 

▶Depth

Depth는 흔히 '깊이'라는 의미로 사용되며, 코드에서는 호출 계층의 깊이를 의미한다. 예를 들어, 메서드 A가 메서드 B를 호출하고, 메서드 B가 메서드 C를 호출한다면 이 코드의 Depth는 3이 된다. 이렇게 여러 메서드가 연쇄적으로 호출되는 구조가 복잡해질수록 코드의 Depth는 깊어진다. Depth가 깊어지면 코드가 복잡하게 느껴지고 이해하기 어려워지기 때문에, Depth는 코드의 복잡도를 나타내는 중요한 요소 중 하나로 간주된다.

---

▶Depth가 깊어질 때의 문제점

Depth가 깊어지면 여러 가지 문제점이 생긴다. 우선, 코드의 가독성이 떨어진다. 호출 계층이 너무 깊어지면 코드의 흐름을 따라가는 것이 매우 어려워진다. 이로 인해 다른 개발자, 혹은 나 자신도 나중에 코드를 다시 볼 때 그 흐름을 이해하기 어려워질 수 있다.

 

또한, Depth가 깊으면 디버깅과 유지보수가 매우 힘들어진다. 예를 들어, A 메서드에서 오류가 발생했을 때 이 오류가 B, C, 혹은 그 이상에서 유발된 것인지 파악하기 어렵다. 이 때문에 코드의 문제를 찾고 해결하는 데 시간이 많이 걸릴 수 있다.

 

더불어, Depth가 깊은 구조는 테스트에도 부정적인 영향을 준다. 각 호출 계층마다 다른 메서드에 의존하고 있으므로, 특정 기능을 테스트하려면 그 이전 단계에서의 상태도 모두 고려해야 한다. 이로 인해 유닛 테스트를 작성하기 어려워지고, 코드가 버그에 취약해질 가능성이 높아진다.

---

▶Depth가 깊어지는 이유

Depth가 깊어지는 이유는 다양하다. 첫 번째로는 메서드들이 지나치게 서로 의존하는 경우다. 한 메서드가 여러 다른 메서드를 호출하면서 복잡한 흐름을 만들기 때문이다. 또, 하나의 메서드가 너무 많은 책임을 지고 있는 경우에도 Depth가 깊어진다. 예를 들어, 모든 로직을 하나의 메서드에 몰아넣고, 그 메서드가 여러 하위 메서드를 호출하게 된다면 Depth는 금세 깊어질 것이다.

 

이 외에도 객체 간의 강한 결합이 Depth를 증가시키는 주요 원인이다. 클래스와 객체들이 서로 지나치게 얽혀 있는 경우, 특정 기능을 구현하거나 수정할 때 여러 클래스를 동시에 고려해야 한다. 이로 인해 메서드 호출이 계속해서 중첩되고, 결과적으로 Depth가 깊어지게 된다.

---

▶Depth를 줄이기 위한 방법

Depth를 줄이기 위해 가장 중요한 것은 코드의 책임을 분리하는 것이다. 하나의 메서드가 너무 많은 역할을 담당하지 않도록 하여, 메서드가 단일 책임만 가지도록 설계해야 한다. 이를 위해 단일 책임 원칙(Single Responsibility Principle, SRP)을 따르는 것이 좋다. SRP는 하나의 클래스나 메서드는 단 하나의 책임만 가져야 한다는 원칙이다. 이렇게 하면 코드의 가독성이 좋아지고 유지보수성이 높아진다.

 

또한, 디자인 패턴을 도입하는 것도 Depth를 줄이는 데 효과적이다. 예를 들어, 팩토리 패턴이나 전략 패턴을 사용하면 객체 생성과 로직 구현을 분리할 수 있어서 Depth를 줄이고 코드의 구조를 더 명확하게 만들 수 있다. 이러한 패턴을 통해 객체 간의 결합도를 낮추고, 코드의 각 부분이 독립적으로 동작할 수 있도록 하는 것이 중요하다.

 

그리고 메서드를 적절히 분리하여 Depth를 줄일 수 있다. 예를 들어, 하나의 긴 메서드를 여러 개의 작은 메서드로 나누어 각 메서드가 하나의 역할만 담당하도록 만드는 것이다. 이렇게 하면 호출 계층이 더 얕아지고, 코드의 가독성과 유지보수성이 크게 개선된다.

 

마지막으로, 재귀 호출을 사용할 때도 주의가 필요하다. 재귀 호출은 반복적인 작업을 간단하게 표현할 수 있지만, Depth를 매우 깊게 만들 수 있다. 따라서 재귀 호출을 사용할 때는 반드시 탈출 조건을 명확히 설정하고, Depth가 너무 깊어지지 않도록 제한하는 것이 중요하다.

---

▶개선된 코드 예시

Depth를 줄이기 위해 개선한 코드의 예시로, 원래는 updateGamingSetup과 partialUpdateGamingSetup에서 중복된 로직이 있었다. 이를 하나의 공통 메서드로 분리하여 Depth를 줄였다.

private Optional<GamingSetupResponseDto> updateOrPartialUpdateGamingSetup(String player, GamingSetupRequestDto gamingSetupRequestDto) {
    Optional<GamingSetup> existingSetup = gamingSetupRepository.findByPlayer(player);
    if (existingSetup.isPresent()) {
        GamingSetup gamingSetup = existingSetup.get();
        updateEntityFromDto(gamingSetupRequestDto, gamingSetup);
        GamingSetup updatedSetup = gamingSetupRepository.save(gamingSetup);
        return Optional.of(convertToResponseDto(updatedSetup));
    }
    return Optional.empty();
}

→ 중복된 로직을 updateOrPartialUpdateGamingSetup이라는 메서드로 분리하여 Depth를 줄였다. 이렇게 하면 각 메서드가 하는 일이 더 명확해지고, 코드를 읽는 사람이 이해하기 쉽게 된다.

---

Depth는 코드의 복잡도를 나타내는 중요한 요소이며, Depth가 깊어질수록 코드의 가독성, 유지보수성, 테스트 용이성이 모두 떨어지게 된다. 따라서 Depth를 관리하고 줄이는 것은 클린 코드의 핵심 원칙 중 하나다. 이를 위해 메서드와 클래스의 책임을 명확히 하고, 디자인 패턴을 도입하며, 메서드를 적절히 분리하는 등의 노력이 필요하다.