[클린 코드] 챕터2 의미 있는 이름2

2.10 메소드 이름

메소드 이름은 동사나 동사구가 적합하다. postPayment, deletePage, save 등이 좋은 예이다. 접근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 자바 빈(javabean) 표준에 따라 값 앞에 get, set, is를 붙인다.

String name = employee.getName();
Customer.setName("mike");
if(paycheck.isPosted){
 ...
}

생성자(constructor)를 중복해 정의(overload)할 때는 정적 팩토리 메소드를 사용한다. 메소드는 인수를 설명하는 이름을 사용한다.

Complex fulcrumPoint = Complex.FromRealNumber(23.0); //이 코드가
Complex fulcrumPoint = new Complex(23.0); //이 코드보다 낫다.

생성자 사용을 제한하려면 해당 생성자를 private로 선언한다.

2.11 기발한 이름은 피하라

이름이 너무 기발하면 저자와 유머 감각이 비슷한 사람만, 그리고 농답을 기억하는 동안만, 이름을 기억한다. HolyHand라는 함수가 무엇을 하는지 알겠는가? 재밌지만 DeleteItems가 더 낫다. 재미난 이름보다 명확한 이름을 선택하라.

간혹 프로그래머가 재치를 발휘해 구어체나 속어를 이름으로 사용하는 사례가 있다. 예를 들어, kill() 대신에 whack()-(후려치다) 이라고 부르거나 abort()대신 eatMyShort()-(꿈 깨!)라고 부른다. 특정 문화에서만 사용하는 농담은 피하는 편이 좋다. 의도를 분명하고 솔직하게 표현하라.

2.12 개념 하나에 단어 하나를 사용하라

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 예를 들어, 똑같은 메소드를 클래스마다 fetch, retrieve, get이라고 제가가 부르면 혼란스럽다. 어느 클래스에서 어느 이름을 썼는지 기억하기 어렵다.

메소드 이름은 독자적이고 일관적이어야 한다. 그래야 주석을 뒤져보지 않고도 프로그래머가 올바른 메소드를 선택할 수 있다. 마찬가지로 동일한 코드 기반에 controller, manager, driver를 섞어 쓰면 혼란스럽다. DeviceManger와 ProtocolController는 근본적으로 어떻게 다른가? 어째서 둘 다 Controller가 아닌가? 왜 둘 다 Manager가 아닌가? 이름이 다르면 독자는 당연히 클래스도 다르고 타입도 다르리라 생각한다.

2.13 말장난을 하지 마라

한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다. “한 개념에 한 단어를 사용하라”는 규칙을 따랐더니, 예를 들어 많은 클래스에 add라는 메소드가 생겼다. 모든 add메소드의 매개변수와 반환 값이 의미적으로 똑같다면 문제가 없다.

하지만 때로는 프로그래머가 같은 맥락이 아닌데도 ‘일관성’을 고려해 add라는 단어를 선택한다. 예를 들어, 지금까지 구현한 add 메소드는 모두가 기존 값 두 개를 더하거나 이어서 새로운 값을 만든다고 가정하자.

새롭게 작성하는 메소드는 집합에 값 하나를 추가한다. 이 메소드를 add라 불러도 괜찮을까? add라는 메소드가 많으므로 일관성을 지킬려면 add라 불러야지 않을까? 하지만 새 메소드는 기존 add메소드와 맥락이 다르다. 그러므로 insert나 append라는 이름이 적당하다. 새 메소드를 add라 부른다면 이는 말장난이다.

프로그래머는 코드를 최대한 이해하기 쉽도록 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드가 목표다.

의미를 해독할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 저자에게 있는 잡지 모델이 바람직하다.

2.14 해법 영역에서 사용하는 이름을 사용하라

코드를 읽을 사람도 프로그래머라는 사실을 명심한다. 그러므로 전산 용어, 알고리즘 이름, 페턴 이름, 수학 용어 등을 사용해도 괜찮다. 무조건 문제 영역에서 모든 이름을 가져오면 같은 개념을 다른 이름으로 이해하던 동료들이 매번 고객에게 의미를 물어야하므로 현명하지 못하다. (해법 영역 = 기술 영역)

프로그래머에게 익숙한 기술 개념은 아주 많다. 기술적인 개념에는 기술적인 이름이 가장 적합한 선택이다.

2.15 문제 영역과 관련 있는 이름을 사용하라

적절한 ‘프로그래머 용어’가 없다면 문제 영역에서 이름을 가져온다. 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다. 문제 영역 개념과 관련 깊은 코드라면 문제 영역에서 이름을 가져와야 한다. (문제 영역 = 도메인)

2.16 의미 있는 맥락을 추가하라

스스로 의미가 분명한 이름도 있다. 하지만 대다수 이름은 그렇지 못하다. 그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.

예를들어 firstName, lastName, street, city, state, zipcode라는 변수가 있다. 변수를 훑어보면 주소라는 사실을 금방 알수있다. 하지만 어느 메소드가 state 변수 하나만 사용한다면? state변수가 주소 일부라는 사실을 금방 알아챌까?

addr라는 접두어를 추가해 addrFirstName, addrState라고 쓰면 맥락이 좀더 분명해진다. 변수가 좀더 큰 구조에 속한다는 사실이 적어도 독자에게 분명해진다. 물론 Address라는 클래스를 생성하면 더 좋다. 그러면 변수가 좀더 큰 개념에 속한다는 사실이 컴파일러에게도 분명해진다.

2.17 불필요한 맥락을 없애라

‘고급 휘발유 충전소 Gas Station Deluxe’라는 응용 프로그램을 만든다고 하자. 모든 클래스 이름을 GSD로 시작하겠다는 생각은 전혀 바람직하지 못하다. IDE에서 G를 입력하고 자동 완성을 누르면 IDE는 모든 클래스를 열거한다.

일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다.

accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이지만 클래스 이름으로는 부적절하다. 포트 주소, MAC주소, 웹 주소를 구분해야한다면 PostalAddress, MAC, URI라는 이름도 괜찮겠다. 의미가 더 분명해지기 때문이다. 바로 이것이 이름을 붙이는 이유가 아니던가?

2.18 마치면서

좋은 이름을 선택하려면 설명하는 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다. 이것이 제일 어렵다. 우리들 대다수는 자신이 짠 클래스 이름과 메소드 이름을 모두 암기하지 못한다. 암기는 현대적인 도구에게 맡기고, 우리는 문장이나 문단처럼 읽히는 코드 아니면, 적어도 표나 자료 구조처럼 읽히는 코드를 짜는데만 집중해야 마땅하다.

코드를 개선하려는 노력을 중단해서는 안 된다.

참조

로버트 C. 마틴, 『Clean Code 클린 코드』, 박재호, 이해영 옮김, 케이앤피북스(2010), P63-69.