%EB%A6%AC%ED%8C%A9%ED%84%B0%EB%A7%81

이번 포스팅도 어떤 백엔드 서비스의 코드를 리팩터링한 내용을 정리하는 것으로, 이번에는 코드 복잡도 줄인 리팩터링에 대한 내용을 정리한다. 이전에 포스팅했던 ' 가변 Context 클래스는 신중하게 사용하자 '와 ' 고차 함수로 의존성 줄이기 '로 코드의 의존성 문제들이 많이 정리된 상태라서 복잡도 줄이기를 진행할 수 있었다. 아래는 어떤 백엔드 서비스 코드의 리팩터링 전과 후의 코드 복잡도 Cyclomatic Complexity와 NPath Complexity의 수치 변화다. 많이 줄어든 것을 볼 수 있다....

요즘 라이브 서비스의 레거시 코드 리팩터링을 하고 있다. 흔히 가변 상태를 관리하는 Context 클래스가 레거시 코드에 있는 건 새삼스럽지 않았지만, 과도하게 사용하고 있어서 정리가 필요했다. 가변 상태 Context 사용 시 문제점 가변 상태를 가지는 Context 클래스가 2, 3개도 도 아니고 10개쯤 되면 과하다고 생각한다. 이렇게 많은 Context 클래스들이 서로 물고 물리는 종속성을 가지고 각기 다른 클래스에 넘기고, 넘겨받고, 가변 Context의 레퍼런스가 다양한 함수들로 넘겨져 전역 변수처럼 여기저기서 사용되면서 어딘가에서 A가 set을 하고 다른 곳에서는 B가 get을 하는 상황은 코드를 매우 읽기 어렵게 만들었다. 읽기 어렵다는 것은 Context를 수정할 때, 사용처를 모두 추적하는 것이 어렵고, 문제 발생 시 디버깅 역시 어렵다는 것이다.   다른 것보다 이걸 먼저 해결하기로 했다. 이 Context 클래스를 정리하는 리팩터링을 점진적으로 진행하여 총 10개에서 6개를 삭제하고 2개는 사이즈를 많이 줄였다. 프로덕션 코드에서 총 568라인을 삭제했다. 당연히 기능에 변화는 없다. Context를 정리하는 리팩터링이 일단락되어 ...