개발자 99% 커뮤니티에서 수다 떨어요!
[TIL] CLEAN CODE #2. 의미 있는 이름
🗓️ TIL (Today I Learned)
2022.02.20
🔖 오늘 읽은 범위
2장. 의미 있는 이름
🌟 책에서 기억하고 싶은 내용을 써보세요.
2장 의미 있는 이름은 ‘이름을 잘 짓는 간단한 규칙’ 몇 가지를 소개한다.
1. 의도를 분명히 밝혀라
코드 맥락이 명시적으로 나타나도록 짓는다.
정보를 드러내는 이름
자료형을 클래스로 바꾼다
명시적인 이름의 함수로 바꾼다
📌 변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. (p.22)
2. 그릇된 정보를 피하라
코드의 의미를 파악하기 어렵게 만드는 ‘그릇된 단서'를 남기지 마라
그릇된 단서
널리 쓰이는 의미가 이미 있는 단어 (hp, axis,...)
서로 흡사한 이름들을 함께 사용
일관성이 떨어지는 표기
O, l처럼 영어와 숫자가 헷갈리는 변수
3. 의미 있게 구분하라
읽는 사람이 차이를 구분하도록 지어라
안 좋은 예: 연속된 숫자(a1, a2, ... aN), 불용어(Product, ProductInfo, ProductData)
4. 발음하기 쉬운 이름을 사용하라
예를 들어 genymdhms는 generate date, year, month, day, hour, minute, second
무지성으로 줄이려다가 생긴 부작용이 아닐까. 맥락을 아는 사람이 아니라면 의미있는 단위로 끊어 읽기 어렵겠다.
5. 검색하기 쉬운 이름을 사용하라
검색하기 쉬운 이름이 상수보다 좋다.
이름 길이는 범위 크기에 비례해야 한다. (p.28)
이름을 의미있게 지으면 함수가 길어진다. 하지만 WORK_DAYS_PER_WEEK를 찾기가 얼마나 쉬운지 생각해보라. 그냥 5를 사용한다면 5사 들어가는 이름을 모두 찾은 후 의미를 분석해 원하는 상수를 가려내야 하리라. (p.29)
6. 인코딩을 피하라
변수에 부가 정보를 붙이지 마라
헝가리식 표기법 → 변수 이름에 타입 X. 시대가 변했다.
멤버 변수 접두어 → 접두어 또는 접미어 사용 X. IDE로 눈에 잘보이게 쓰자
인터페이스 클래스와 구현 클래스 → 구현클래스에
Impl붙이는 건 허용
7. 자신의 기억력을 자랑하지 마라
문자 하나만 쓰는 변수는 루프의 반복 횟수 변수에만 쓰자.
그 외에는 독자가 실제 개념으로 변환해야 한다.
8. 클래스 이름
클래스 이름과 객체 이름은 명사나 명사구가 적합하다.
9. 메서드 이름
메서드 이름은 동사나 동사구가 적합하다.
접근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.
생성자를 오버로드할 때는 정적 팩토리 메서드를 사용한다. 메서드는 인수를 설명하는 이름을 사용한다.
10. 기발한 이름은 피하라
재미난 이름보다 명료한 이름을 선택하라
11. 한 개념에 한 단어를 사용하라
추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 메서드 이름은 독자적이고 일관적이어야 한다.
12. 말장난을 하지 마라
한 단어를 두 가지 목적으로 사용하지 마라
예를 들어, 두 개를 더하는 기능의 add 메서드가 있을 때 집합에 값 하나를 추가하는 메서드를 새로 작성하는 경우 add라 이름을 붙여도 괜찮을까?
맥락이 다르다면 같은 이름을 사용해서는 안된다. 따라서 위의 사례는 insert나 append가 적당하다.
13. 해법 영역에서 가져온 이름을 사용하라
기술 개념에는 기술 이름이 가장 적합한 선택이다.
14. 문제 영역에서 가져온 이름을 사용하라
적절한 ‘프로그래머 용어’가 없다면 문제 영역(도메인)에서 이름을 가져온다.
15. 의미 있는 맥락을 추가하라
스스로 의미가 분명하지 않다면 맥락을 부여한다.
접두어를 추가한다. (적절한 클래스를 만드는 것이 더 좋다) : firstName → addrFirstName
16. 불필요한 맥락을 없애라
이름에 불필요한 맥락을 추가하지 않도록 주의한다.
의미가 분명한 경우에 짧은 이름이 긴 이름보다 좋다.
accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나 클래스 이름으로는 적합하지 못하다.
💭 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
📌 프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다. (p.34)
지금까지 변수명을 짓는 데에 나름 신경을 썼다고 생각했지만 3번 ‘의미있게 구분하라’와 11번 ‘한 개념에 한 단어를 사용하라'는 잘 지키지 못했던 듯 하다. 특히 의미 있게 구분하기에 있는 연속된 숫자 변수는 첫 직장에서 사수님에게 SQL 쿼리 짜면서 그 분이 짜는 스타일에 따라가다 보니 자연스레 몸에 익은 습관같은 것인데 너무 무지성으로 따라했구나 싶다.
이 장을 관통하는 한 문장을 뽑자면, “프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다.” 라는 부분인 듯 하다. 사람의 뇌는 한계가 있고 최소의 비용으로 최대한 효율적으로 일하려 하기 때문에 코드는 최대한 간결하고 직관적이고 명쾌해야 쓸데없는 부분에 소요되는 에너지를 줄일 수 있다고 생각한다. 불필요함을 덜어내고 딱 필요하고 적절한 것에만 집중하는 것. 코딩에도, 삶에도 필요한 자세인 것 같다.
🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
불용어(noise word) : 자주 등장하지만 문맥적으로 큰 의미가 없는 단어.
정적 팩토리 메서드 : 객체 생성을 흔히 사용하는 생성자가 아닌 정적(static) 메서드로 하는 것. 의미있는 이름을 지어 객체를 생성할 수 있다는 장점이 있다. 또한, 객체 생성만 할 뿐 구현부는 외부에 보여주지 않고 숨겨서 의존성을 제거할 수 있다.
from: 하나의 매개 변수를 받아서 인스턴스를 생성해서 반환
of: 여러 개의 매개 변수를 받아서 인스턴스를 생성해서 반환
getInstance: 인스턴스를 생성해서 반환. 항상 동일한 인스턴스를 반환한다는 보장X
newInstance: 항상 새로운 인스턴스를 생성해서 반환
get[OtherType]: 특정한 타입의 인스턴스를 생성해서 반환
new[OtherType]: 특정한 타입의 새로운 인스턴스를 생성해서 반환
VISITOR 패턴 : 알고리즘을 객체 구조에서 분리시키는 디자인 패턴. 이렇게 분리하면 구조를 수정하지 않고도 실질적으로 새로운 동작을 기존의 객체 구조에 추가할 수 있게 된다.
JobQueue : 개별적으로 실행되는 스크립트 블럭을 하나의 잡(Job)이라 하고, 이러한 잡들(Jobs)를 적재하는 FIFO큐가 잡큐(JobQueue)이다.