TIL (Today I Learned)

2022.02.20

오늘 읽은 범위

2장. 의미 있는 이름

책에서 기억하고 싶은 내용을 써보세요.

의도를 분명히 밝혀라

• 의도가 분명하게 이름을 지으라

• 변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다. 변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.

• 문제는 코드의 단순성이 아니라 코드의 함축성이다. 다시 말해, 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다.

그릇된 정보를 피하라

• 프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다.
  나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안된다.

  • 여러 계정을 그룹으로 묶을 때, 실제 List 가 아니라면, accountList 라 명명하지 않는다.
    프로그래머에게 List라는 단어는 특수한 의미다. 계정을 담는 컨테이너가 실제 List가 아니라면 프로그래머에게 그릇된 정보를 제공하는 셈이다. 그러므로 accountGroup, bunchOfAccounts, 아니면 단순히 Accounts 라 명명한다.

• 서로 흡사한 이름을 사용하지 않도록 주의한다.

• 유사한 개념은 유사한 표기법을 사용한다. 일관성이 떨어지는 표기법은 그릇된 정보다.

의미 있게 구분하라

• 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다.

• 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다. 연속적인 숫자를 덧붙인 이름(a1, a2, ..., aN)은 의도적인 이름과 정반대다. 이런 이름은 그릇된 정보를 제공하는 이름도 아니면, 아무런 정보를 제공하지 못하는 이름일 뿐이다.

• 불용어를 추가한 이름 역시 아무런 정보도 제공하지 못한다.
  Product라는 클래스가 있다고 가정하자. 다른 클래스를 ProductInfo 혹은 ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다. Info나 Data는 a, an, the 와 마찬가지로 의미가 불분명한 불용어다.

• 불용어는 중복이다. 변수 이름에 variable 이라는 단어는 단연코 금물이다. 표이름에 table이라는 단어도 마찬가지다.

• 명확한 관례가 없다면 변수 moneyAmount는 money와 구분이 안 된다. customerInfo는 customer와, accountData는 account와, theMessage는 message와 구분이 안 된다.

발음하기 쉬운 이름을 사용하라

검색하기 쉬운 이름을 사용하라

• 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다.

• 이름 길이는 범위 크기에 비례해야 한다. 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.

인코딩을 피하라

• 자바 프로그래머는 변수 이름에 타입을 인코딩할 필요가 없다. 객체는 강한타입(strongly-typed)이며, IDE는 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다.

  • PhoneNumber phoneString; // 타입이 바뀌어도 이름은 바뀌지 않는다!

• 멤버 변수에 m_ 이라는 접두어를 붙일 필요도 없다. 코드를 읽을수록 접두어는 관심 밖으로 밀려난다.

• 인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름을 택하겠다. ShapeFactoryImp나 심지어 CShapeFactory가 IShapeFactory보다 좋다.

자신의 기억력을 자랑하지 마라

• 문자 하나만 사용하는 변수 이름은 문제가 있다. 루프에서 반복 횟수를 세는 변수 i,j,k는 괜찮다(l은 절대 안된다!)단, 루프 범위가 아주 작고 다른 이름과 충돌하지 않을 때만 괜찮다.

• 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다.

클래스 이름

• 클래스 이름과 객체 이름은 명사나 명사구가 적합하다.

메서드 이름

• 메서드 이름은 동사나 동사구가 적합하다.
  접근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.

• 생성자(Constructor)를 중복정의(overload)할 때는 정적 팩토리 메서드를 사용한다.

기발한 이름은 피하라

한 개념에 한 단어를 사용하라

• 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.

• 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.

말장난을 하지 마라

• 한 단어를 두 가지 목적으로 사용하지 마라

  • 지금까지 구현한 add메서드는 모두가 기존 값 두 개를 더하거나 이어서 새로운 값을 만든다고 가정하자. 새로 작성하는 메서드는 집합에 값 하나를 추가한다. 새로 작성하는 메서드는 기존 add 메서드와 맥락이 다르기 때문에 insert 나 append라는 이름이 적당하다.

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

해법 영역에서 가져온 이름을 사용하라

• 코드를 읽을 사람도 프로그래머라는 사실을 명심한다.

• 기술 개념에는 기술 이름이 가장 적합한 선택이다.

문제 영역에서 가져온 이름을 사용하라

• 적절한 '프로그래머 용어'가 없다면 문제 영역에서 이름을 가져온다.

의미 있는 맥락을 추가하라

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

불필요한 맥락을 없애라

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

  • accoutAddress 와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나 클래스 이름으로는 적합하지 못하다.

마치면서

• 좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다. 이것이 제일 어렵다.

• 사람들이 이름을 바꾸지 않으려는 이유 하나는 다른 개발자가 반대할까 두려워서다. 우리들 생각은 다르다. 오히려 좋은 이름으로 바꿔주면 반갑고 고맙다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

입사한지 1~2년차 즈음 나보다 훨씬 경력이 많으신 분께서 내가 작성한 코드를 보고 클래스 명이 이게 뭐냐며, 변수명은 또 왜 이러냐며 그 당시엔 2장의 내용인 '의미 있는 이름' 에 대해서 자세히 알고 있지 못했고 또한 이름들에 대해 지적만을 해주시고 왜 이렇게 사용하면 안 되는지에 대해서는 어떠한 설명이나 피드백도 제공해주지 않은채 그저 '지적' 만을 하셨던 기억이 문득 났다.

그리고 후에 '의미 있는 이름' 에 대한 내용 모두는 아니지만 어느정도의 내용을 알게 된 후 다른 사람이 작성한 코드에서 '의미 있는 이름' 의 범주에서 벗어난 이름들을 보게 되었을 때 나 또한 속으로 이분 이름을 왜 이렇게 했지??? 라고 혼자 혀를 끌끌차며 코드를 읽은 기억도 났다.

현재 프로그래밍을 하면서 '의미 있는 이름' 짓기에 심사숙고 할 여유도 없이 일정이 촉박한 작업을 하게 될 때는 '의미 있는 이름'으로 명확하게 읽히도록 작성해야 한다는 것을 알면서도 의미있고 명확히 읽히는 이름으로 무엇을 사용할지 생각하는 시간이 아깝다는 잠깐의 생각에 넘어가 르블랑의 법칙처럼 '나중에 여유있을 때 다시 고쳐야지' 라고 생각하며 프로그래밍을 한 기억들도 났다.

나중에 여유있을 때 다시 고쳐둔적도 물론있긴 하지만, 그건 정말 몇 안되는 경우들이였다는 것을 다시 상기시키자. 이름에 대해 고민하는 그 순간이 아무리 여유가 없고 일정이 촉박하다 할 지라도 그 때 좀 더 시간을 들여 심사숙고하며 지은 이름들이 미래의 나 혹은 함께 일하는 동료들에게 더할 나위없이 좋은 코드였다는 것을 잊지말도록 하자.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 불용어(noise word) - 검색엔진이 검색에서 무시해버리는 단어 또는 검색엔진이 데이터베이스를 구축할때 색인에서 제외해버리는 단어를 뜻한다. 라고 나오는데 이 책에서는 전반적으로 코드의 맥락에서 쓸데없이 사용된 단어를 의미하는 것 같다.
  영어에서의 불용어의 예 : a, an, is, are, if, but, this, may.....