2022년 7월 14일 TIL - 지나친 추상화는 오히려 가독성을 저해한다

 

메가테라 백엔드 트레이닝 4주차 퀘스트 중 하나로 주어진 '깐깐한 계산기'에서 주요하게 구현해야 하는 부분에는 사용자가 입력한 수식이 조건에 맞는 수식인지를 검사해야 하는 부분이 있다. 수식을 검사하는 과정 역시 테스트 코드를 작성하면서 구현해야 하기 때문에 수식을 검사하는 작업 흐름이 클래스나 메서드로 분리를 시켜주고, 그 분리된 메서드를 테스트 코드를 작성하면서 구현하는 과정을 거치게 된다.

 

엊그제 처음으로 받은 코드 리뷰를 바탕으로 수정을 거쳐 PR을 재차 올렸던 소스코드에 다시 코드 리뷰가 올라왔다. 주요한 리뷰는 수식 조건 검사기 클래스를 구현한 부분과 그 테스트 코드에 집중되어 있었다. 리뷰들 중에 하나로 프로세스의 유의미한 추상화가 이루어져야 할 것이라는 내용이 있었다.

 

처음에 수식 검사기 클래스를 작성할 때에는 검사기가 어떤 과정을 거치면서 수식을 검사해야 할까를 생각하면서 검사기 클래스의 구조를 구상했다. 검사기 내부에서도 추상화를 통한 작업의 명확한 구분을 해 줘야겠다는 생각이 들었다. 그래서 먼저 수식을 구성하는 숫자나 연산자 같은 문자열들이 각각 띄어쓰기를 기준으로 몇 개 들어오는지를 검사하고, 그 검사를 통과하면 그 다음 검사로 숫자나 연산자 문자열에 적법하지 않는 문자가 있는지 검사하도록 하는 프로세스를 구상했다. 그리고 구상한 메서드들의 구체적인 내용과 테스트 코드를 병행해서 작성했다.

 

 

코드 리뷰와 함께 소스코드를 다시 돌아보면서 짐작해본 문제점들은 이렇다. 두 개의 세부 메서드로 나뉘어진 검사 메서드를 테스트 코드에서 각각 테스트해야 하는데, 검사 메서드에서 검사를 위해 사용하는 수식은 클래스의 멤버 변수를 참조하는 구조로 작성되어 있었다. 따라서 테스트 코드에서 각 메서드를 테스트하기 위해서는 테스트 전마다 일일이 클래스의 멤버 변수를 재할당해줘야 했다. 이는 테스트 코드의 가독성 저해로 이어졌다. 

 

또다른 문제로는 각 숫자와 연산자에 적법하지 않은 문자가 있는지 검사하는 두 번째 메서드에서는 숫자가 하나만 주어진 경우와 숫자 둘과 연산자가 모두 주어진 경우들을 전부 고려할 수 있어야 했다. 따라서 조건에 따라 세부적으로 검사해야 하는 분기가 이루어져야 했고, 이로 인해 중첩 조건문 구조가 발생하면서 소스코드의 가독성이 저해되었다.

 

 

구조를 개선하기 위해 두 개의 세부 메서드에서 검사를 나눠서 수행하도록 한 방식을 합쳐서 하나의 메서드에서 모든 조건 검사를 수행하도록 변경을 시도했다. 세부 메서드로 나뉘었던 내용들이 하나로 합쳐지니 이제는 검사를 위해 필요한 수식이 검사 이전에 필드화될 필요 없이 하나로 합쳐진 메서드를 호출할 때 인자로 전달받아 바로 사용될 수 있는 구조가 되었고, 이에 테스트 코드에서도 메서드에 대한 테스트를 수행하기 전 클래스를 재할당해줄 필요 없이 테스트할 수식을 인자로 전달해주기만 하면 되도록 되었기 때문에 테스트 코드의 구조도 명확해지는 결과를 가져올 수 있었다.

 

추상화의 수준을 어느 정도의 깊이로 가져갈지 결정하는 것은 결코 쉽지 않다. 그렇지만 무작정 작업의 단위를 작은 단위로 쪼개는 것이 능사가 아니라, 추상화할 작업의 의미를 어떻게 부여해야 구조가 명확해질 것인지를 고민하는 게 우선되어야 할 것이라는 점을 생각해볼 수 있었다.