728x90
반응형
🔥해당 글은 프로젝트 팀원과 함께 프로젝트 퀄리티 및 더 나은 개발자가 되기 위하여 북 스터디를 진행하였습니다.
- 소프트웨어에서 이름은 어디에나 쓰인다.
- 이 장에서는 이름을 잘 짓는 간단한 규칙을 몇 가지 소개한다.
의도를 분명히 밝혀라
- 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
- 그러므로, 이름을 주의 깊게 살펴 더 나은 이름이 떠오르면 개선하는 것이 좋다.
- 수행 기능 또는 사용 방법을 나타내기 위해 주석이 필요하다면 그건 의도를 분명히 드러내지 못했다는 말이다.
- 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다.
- 단순히 이름만 고쳐도 함수가 하는 일을 이해하기 쉽다. 이것이 좋은 이름이 주는 위력이다.
그릇된 정보를 피하라
- 프로그래머는 코드에 그릇된 단서는 의미를 흐리기 때문에 남겨서는 안 된다.
- 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안된다.
- 서로 흡사한 이름을 사용하지 않도록 주의해야 한다.
의미 있게 구분하라
- 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다.
- 동일한 범위 안에서 다른 두 개념에 같은 이름을 사용하지 못한다.
- 그렇기 때문에 프로그래머는 한쪽 이름을 마음대로 바꾸고 싶은 유혹에 빠진다.
- 어떤 프로그래머는 철자를 살짝 바꿨다가 나중에 철자 오류를 고치는 순간 컴파일이 불가능한 상황에 빠진다.
- 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다.
- 이름이 달라야 한다면 의미도 달라져야 한다.
- 읽는 사람이 차이를 알도록 이름을 지어야 한다.
발음하기 쉬운 이름을 사용하라
- 발음하기 어려운 이름은 토론하기도 어렵기 때문에, 발음하기 쉬운 이름은 중요하다.
- 프로그래밍은 사회 활동이라고 볼 수 있기 때문에 발음하기 쉬운 이름을 사용하는 것이 좋다.
- 발음하기 좋은 단어로 코드를 구현한다면 프로그래머 간 지적인 대화가 가능해진다.
검색하기 쉬운 이름을 사용하라
- 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 눈에 쉽게 띄지 않는 문제점이 있다.
- 짧은 이름보다 긴 이름이 좋고, 검색하기 쉬운 이름이 상수보다 좋다.
- 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하기도 하다.
public final static int realDaysPerIdealDay = 4;
public final static int WORK_DAYS_PER_WEEK = 5;
int sum = 0;
for (int j = 0; j < WORK_DAYS_PER_WEEK; j++){
int realTaskDays = taskEstimate[j] * realDaysPerIdealDay;
int realTaskWeeks = (realTaskDays / WORK_DAYS_PER_WEEK);
sum += realTaskWeeks;
}
이름을 의미 있게 지으면 함수명이 길어지지만 검색하기 쉬워진다.
인코딩을 피하라
- 문제 해결에 집중하는 개발자에게 인코딩은 불필요한 정신적 부담이 된다.
- 인코딩한 이름은 거의 발음하기 어려워 오타가 생기기 쉽다.
헝가리식 표기법
- 규칙
- 포트란은 첫 글자로 유형을 표현했다.
- 초창기 베이식은 글자 하나에 숫자 하나만 허용했다.
- 헝가리식 표기법은 기존 표기법을 완전히 새로운 단계로 끌어올렸다.
- 자바
- 자바 프로그래머는 변수 이름에 타입을 인코딩할 필요가 없다.
- IDE는 코드를 컴파일하지 않아도 타입 오류를 감지할 수 있다.
- 따라서, 이제는 헝가리식 표기법이나 기타 인코딩 방식은 오히려 방해가 된다.
멤버 변수 접두어
사람들은 접두어(또는 접미어)를 무시하고 이름을 해독하는 방식을 빨리 익힌다. ex) m_dsc → description
코드를 읽을수록 접두어는 관심 밖으로 밀려난다. 결국 접두어는 옛날에 작성한 구닥다리 코드라는 징표가 돼버린다.
자신의 기억력을 자랑하지 마라
- 코드를 읽으면서 변수 이름을 본인만 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.
- 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고다.
- 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용하여 남들이 이해하기 쉽게 구현하기 때문이다.
클래스/메서드 이름
- 클래스 이름과 객체 이름은 명사나 명사구가 적합하다. ex) Customer, WikiPage, Account, AddressParser 등
- 메서드 이름은 동사나 동사구가 적합하다. ex) postPayment, deletePage, save 등
- 접근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get, set, is 등을 붙인다.
- 생성자를 중복 정의할 때는 정적 팩토리 메서드를 사용한다. 메서드는 인수를 설명하는 이름을 사용한다.
기발한 이름은 피하라
- 이름이 너무 기발하면 작성자와 감각이 비슷한 사람만 그 이름을 기억한다.
- 의도를 분명하게 하고 솔직하게 표현된 이름이 좋다.
한 개념에 한 단어를 사용하라
- 추상적인 개념 하나에 단어 하나를 선택해야 한다.
- 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 각각 다르게 부르면 어느 클래스에서 어느 이름을 사용했는지 기억하기 어렵다.
- 이름을 기억하지 못한다면 헤더와 과거 코드 예제를 살펴보며 시간을 많이 소모할 수 있다.
- 그러므로, 메서드 이름은 독자적이고 일관적이어야 한다. 그래야 주석을 보지 않고 올바른 메서드를 선택할 수 있다.
말장난을 하지 마라
- 목적
- 한 단어를 두 가지 목적으로 사용하면 안 된다.
- 프로그래머는 코드를 최대한 이해하기 쉽게 작성해야 한다.
- 집중적인 탐구가 필요한 코드가 아니라 대충 봐도 이해가 가능한 코드 작성이 목표다.
- 의미를 해독할 책임이 독자에게 있는 논문이 아니라 의도를 밝힐 책임이 저자에게 있는 잡지가 바람직하다.
해법 영역에서 가져온 이름을 사용하라
- 코드를 읽는 사람도 프로그래머다.
- 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
- 모든 이름을 문제 영역에서 가져오는 정책은 현명하지 못하지만, 프로그래머에게 익숙한 기술 개념에는 적합하다.
문제 영역에서 가져온 이름을 사용하라
- 적절한 '프로그래머 용어'가 없다면 문제 영역에서 이름을 가져온다.
- 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어서 파악할 수 있다.
- 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져오는 것이 좋다.
의미 있는 맥락을 추가하라
- 대다수 이름은 의미가 분명한 이름이지 못하다.
- 그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 최후의 수단으로 접두어를 붙인다.
- 함수가 길다면 클래스를 만든 후 세 변수를 클래스에 넣어서 사용하면 맥락이 분명해진다.
- 맥락을 개선하면 함수를 쪼개기가 쉬워지므로 알고리즘도 좀 더 명확해진다.
불필요한 맥락을 없애라
- 일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다.
- 이름에 불필요한 맥락을 추가하지 않도록 주의한다.
- 예를 들어, Address는 클래스 이름으로 적합하다. 포트 주소, MAC 주소, 웹 주소를 구분해야 한다면 PastalAdderss, MAC, URI라는 이름도 괜찮다. 그러면 의미가 더 분명해진다.
- 이것이 이름을 붙이는 이유다.
결론
어렵지만.. 좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다.
우리 분야 사람들이 이름 짓는 방법을 제대로 익히지 못하는 이유가 바로 여기에 있다.
오히려 좋은 이름으로 바꿔주면 너무 고맙지만, 사람들이 이름을 바꾸지 않으려는 이유 하나는 다른 개발자가 반대할까 두려워서다.
어느 코드 개선 노력과 마찬가지로 이름 역시 나름대로 바꿨다가 누군가 질책할지도 모른다.
그렇다고 코드를 개선하려는 노력을 멈추면 안 된다.
다른 개발자가 구현한 코드를 리팩토링 한다면 문제 해결 목적으로 이름을 개선하는 것이 좋다.
그렇게 하면 단기적인 효과는 물론 장기적인 이익도 보장한다!
728x90
반응형
'📚 서적 및 학습자료 > 클린 코드' 카테고리의 다른 글
[클린 코드] Clean Code 4장. 주석 (0) | 2023.07.28 |
---|---|
[클린 코드] Clean Code 3장. 함수 (0) | 2023.07.12 |
[클린 코드] Clean Code 1장. 깨끗한 코드 -Gyunny (0) | 2023.04.04 |