[노개북] 'Clean Code' Assignment #03

TIL (Today I Learned)

2024.01.28

오늘 읽은 범위

• 2장. 의미 있는 이름

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

1. 의도를 분명하게 밝혀라

• 의도가 분명한 이름이 정말로 중요하다.
• 변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.

2. 그릇된 정보를 피하라

• 그릇된 단서는 코드 의미를 흐린다.
• 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다.
• 계정을 담는 컨테이너가 실제 List가 아니라면 프로그래머에게 그릇된 정보를 제공하는 셈
  • 실제 컨테이너가 List인 경우라도 컨테이너 유형을 이름에 넣지 않는 편이 바람직
• 서로 흡사한 이름을 사용하지 않도록 주의한다.
• 유사한 개념은 유사한 표기법을 사용한다. 일관성이 떨어지는 표기법은 그릇된 정보다.

3. 의미 있게 구분하라

• 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다.
• 연속된 숫자를 덧붙이거나 불용어(noise word)를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다.
• ProductInfo, ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다.
• 불용어는 중복이다. 변수 이름에 variable, 표 이름에 table이라는 단어도 마찬가지.
• 명확한 관례가 없다면 변수 moneyAmount는 money와 구분이 안 된다. customerInfo는 customer와, accountData는 account와, theMessage는 message와 구분이 안 된다. 읽는 사람이 차이를 알도록 이름을 지어라.

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

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

• 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다.
• e라는 문자도 변수 이름으로 적합하지 못하다. e는 영어에서 가장 많이 쓰이는 문자다.
• 긴 이름이 짧은 이름보다 좋다.
• 간단한 메서드에서 로컬 변수만 한 문자를 사용한다. 이름 길이는 범위 크기에 비례해야 한다.
• 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.

6. 인코딩을 피하라

• 유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다.
• 인코딩한 이름은 거의 발음하기 어려우며 오타가 생기기도 쉽다.

멤버 변수 접두어

• 클래스와 함수는 접두어가 필요없을 정도로 작아야 마땅하다.
• 또한 멤버 변수를 다른 색상으로 표시하거나 눈에 띄게 보여주는 IDE를 사용해야 마땅하다.

인터페이스 클래스와 구현 클래스

• 인터페이스 이름은 접두어를 붙이지 않는 편이 좋다.

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

• 독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.
• 루프에서 반복 횟수를 세는 변수 i, j, k는 괜찮다.
• 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다.

8. 클래스 이름

• 클래스 이름과 객체 이름은 명사나 명사구가 적합하다.
  • 좋은 예: Customer, WikiPage, Account, AddressParser
  • 나쁜 예: Manager, Processor, Data, Info, 동사 사용

9. 메서드 이름

• 메서드 이름은 동사나 동사구가 적합하다.
• 접근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 값 앞에 get, set, is를 붙인다.
• 생성자(Constructor)를 중복정의(overload)할 때는 정적 팩토리 메서드를 사용한다. 메서드는 인수를 설명하는 이름을 사용한다.

10. 기발한 이름은 피하라

• 재미난 이름보다 명료한 이름을 선택하라.
• 의도를 분명하고 솔직하게 표현하라.

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

• 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
• 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.
• 일관성 있는 어휘는 코들르 사용할 프로그래머가 반갑게 여길 선물이다.

12. 말장난을 하지 마라

• 한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.
• 프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다.
• 대충 훑어봐도 이해할 코드 작성이 목표다.

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

• 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
• 모든 이름을 문제 영역(domain)에서 가져오는 정책은 현명하지 못하다.
• 기술 개념에는 기술 이름이 가장 적합한 선택이다.

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

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

15. 의미 있는 맥락을 추가하라

• 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.

16. 불필요한 맥락을 없애라

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

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

• 팀 프로젝트를 하면서 네이밍 규칙을 정하는 걸 중요시 했었다. 당시에는 '조금 번거롭지 않나?' 하는 생각이 들었지만 오늘 2장을 읽고 나서 '좋은 rule이었구나..' 하는 생각이 들었다.
• 변수 이름을 어떻게 지어야 할지 어렴풋이 알게 되었다. 앞으로 프로젝트를 진행하면서 오늘 읽은 내용을 적용해 봐야 겠다.

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

• 아무래도 Java 기반으로 쓰여진 책이라서 코드를 이해하는 게 힘들었다. JavaScript 기반으로 클린코드를 정리한 GitHub이 있던데 참고하며 읽어야겠다.