냄새와 휴리스틱

이번 장에서는 코드 냄새에 관해서 얘기하고 있습니다. 직접 리팩토링하면서 겪은 경험에 관해 얘기하고 있는 부분이기에 어쩌면 이번 책에서 가장 핵심적인 내용이라고 볼 수 있습니다. 읽으면서 기록으로 남길만한 정보들은 남겨보도록 하겠습니다.

주석

부적절한 정보

다른 시스템에 작성될 정보를 코드 주석으로 다는 것은 적절하지 않습니다. 굳이 작성한다면 작성자, 최종 수정 일자, 소프트웨어 번호 등과 같은 메타 정보만 주석으로 작성합니다. 주석은 코드와 설계에 대한 설명을 부연하는 수단입니다.

환경

여러 단계로 빌드하고 테스트해야 한다

가장 이상적인 빌드는 명령어 하나로 빌드가 이루어지는 것입니다. 빌드를 하기 위해서 이것저것 파일을 찾고 명령어를 칠 필요가 존재하지 않아야 합니다. 요즘은 IDE가 이러한 빌드를 잘 제공하고 있기에 이러한 걱정이 조금은 줄어든 것 같습니다.

 

테스트 또한 마찬가지입니다. 버튼 하나로 모든 테스트가 실행되는 것이 가장 이상적입니다. 아무리 열악한 환경이어도 쉘 명령 하나로 테스트가 가능해야 합니다. 빠르고 쉽고 명백한 것이 핵심입니다.

함수

너무 많은 인수

함수의 인수는 작을수록 좋습니다. 없는 게 가장 이상적이라고 하는데 이는 함수 간의 의존성을 줄이려는 의도로 생각됩니다. 코드를 작성할 때 습관적으로 인수를 사용하곤 하는데 줄이기 위해 설계에 시간을 더 쏟아봐야 할 것 같습니다.

플래그 인수

함수 안에서 플래그가 사용된다면 그 자체로도 이미 많은 역할을 담고 있다는 의미입니다. 플래그가 사용되는 함수라면 함수 설계를 다시 한번 생각해봐야 할 것입니다.

일반

당연한 동작을 구현하지 않는다

Day day = DayDate.StringToDay(String dayName);

이 코드를 보면 무슨 생각이 떠오르시나요? Monday가 입력되면 Day.MONDAY를 반환할 것이라고 예상됩니다. 이렇듯 함수는 처음 보는 사람이 보더라도 동작을 예상할 수 있도록 구현해야 합니다. 함수 기능을 직관적으로 이해하기 어렵다면 코드 작성자에 대한 신뢰가 떨어지게 되고 코드를 일일이 찾아보게 될 것입니다.

중복

코드에서 중복을 발견할 때마다 추상화할 기회로 간주하는 습관을 길러야 합니다. 중복된 코드를 하위 루틴이나 다른 클래스로 분리하도록 합니다. 그렇게 되면 사용하는 어휘가 적어지고 그로 인해 구현이 빨라지고 오류가 적어집니다.

 

if/else, switch문을 사용하는 분기 또한 다형성으로 대체할 수 있습니다. 조건문을 사용하게 되면 조건을 거듭 확인하게 되는 중복이기 때문입니다. 저도 코드를 작성할 때 if/else의 거듭적인 확인을 어떻게 처리하는지에 대한 고민을 매번 가지고 있었는데 다형성을 적극적으로 활용해 보도록 하겠습니다.

과도한 정보

클래스나 인터페이스가 가지고 있는 정보가 많아지면 원하지 않더라도 의존성이 생길 수 있습니다. 그렇기에 과도한 정보를 제공하지 않도록 메서드 수, 변수 수를 제한하는 능력을 갖춰야 합니다. 작고 간편하게 만들어서 정보를 제한하도록 하여 결합도를 낮추는 설계를 고민해 봐야 합니다.

기능 욕심

클래스 메서드는 자기 클래스의 변수와 함수에 관심을 가져야 합니다. 다른 클래스의 변수와 함수에 욕심을 내는 메서드라면 해당 위치가 올바른지 고민해볼 필요가 있습니다. 하지만 어쩔 수 없는 경우도 존재합니다. 옮긴 클래스의 역할 상 해당 메서드가 어울리지 않는다고 판단했을 때는 접근을 유동적으로 처리해야 합니다.

조건을 캡슐화하라

인스턴스의 필드로 부울 값이 존재할 때 값을 가져와서 바로 사용했던 것 같습니다. 하지만 이 책에서는 바로 사용하기보다는 캡슐화해서 사용하기를 권장하고 있습니다. 부울 값은 이해하기 어려운 값이기 때문입니다.

if (election.getIsAvailable())

위 코드보다 아래의 코드가 이해하기 쉽습니다.

if (isAvailable(election))

자바

긴 import 목록을 피하고 와일드카드를 사용하라

패키지에서 클래스를 둘 이상 사용한다면 와일드카드를 사용해 패키지 전체를 가져오라고 설명하고 있습니다. 이 점과 관련하여 스터디원들과 얘기를 한 적이 있습니다. 다른 패키지에 동일한 이름의 클래스가 존재하는 경우 명시적으로 사용하는 것이 좋으나 그런 경우가 아닌 경우 와일드카드를 사용하여 장황한 import를 없애는 것이 좋다는 생각을 가지게 되었습니다.

 

요즘은 IDE가 좋아져 간단한 명령으로 와일드카드 import를 명시적 import로 바꿀 수 있다고 합니다. 이러한 IDE의 발전도 와일드카드 사용의 근거가 될 수 있습니다.

이름

적절한 추상화 수준에서 이름을 선택하라

구현을 드러내는 이름은 피해야 합니다. 처음부터 바로 적용하기에는 쉽지 않은 작업이지만 추상화 수준을 고려하여 이름을 선택해야 합니다. 추상화가 높은 수준에 있는 메서드라면 특정 구현체의 동작을 나타내기보다는 범용적으로 대체할 수 있는 이름을 사용해야 합니다.

긴 범위는 긴 이름을 사용하라

이름 길이는 범위 길이에 비례해야 합니다. 범위가 작으면 아주 짧은 이름을 사용해도 괜찮지만, 범위가 길어지면 긴 이름을 사용할 수 있도록 해야 합니다.

이름으로 부수 효과를 설명하라

평소 메서드 이름을 작성할 때 부수 효과는 제외하고 주요한 역할에 대해서만 생각하고 작성했습니다. 부수 효과를 숨기게 되면 곤란해지는 상황이 발생할 수 있기에 하는 일을 모두 기술하는 이름을 사용하는 것을 권장하고 있습니다.