오늘 읽은 범위 : 2장 의미 있는 이름
🙂 책에서 기억하고 싶은 내용을 써보세요.
의도가 분명하게 이름을 지으라
변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다. 변수의 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
그릇된 정보를 피하라
실제 List가 아니라면, 이름에 accountList 와 같이 List라 명명하지 말아야 한다.
서로 흡사한 이름을 사용하지 않아야 한다.
의미 있게 구분하라
읽는 사람이 차이를 알도록 이름을 지어야 한다.
(단순 구분을 위해 productInfo 와 productData로 이름을 나누어 짓는 것은 정말 의미 없는 행동이다.)
클래스 이름
클래스와 객체 이름은 명사, 명사구를 사용한다. (ex. Customer, Account)
매서드 이름
매서드 이름은 동사, 동사구가 적합하다. (ex. postPayment, deletePage)
접근자 → get*, 변경자 → set*, 조건자 → is*
일관성 있는 어휘를 사용하라
같은 프로젝트에 controller, manager, driver를 섞어 쓰면 혼란이 온다.
기술 개념에는 기술 이름이 가장 적합하다
해법 영역(프로그래머가 자주 쓰는 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 의미)의 이름을 우선적으로 사용한다. 적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져온다. (여기서 문제 영역이란 프로그래머 이외 영역, 예를 들면 병원 시스템 개발이라면 병원 관련 용어를 뜻한다.)
불필요한 맥락을 없애라
커피 관련 앱을 만든다고 모든 클래스 이름을 Coffee로 시작하는 것은 전혀 바람직하지 못하다.
🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
이름을 짓는 일은 힘들다. 컴포넌트 이름 고민하느라 한 시간을 흘려보내면 정말 현타가 온다. 그렇다고 결과적으로 마음에 드는 이름이 나오는 것도 아니다. 정말 이게 최선일까 싶은 마음을 떨쳐내지 못하고 찝찝함을 남긴 채 개발을 이어간다.
요즘은 이름을 지을 때 간결한 이름과 그 의도를 온전하게 표현하는 이름 사이에서 고민한다. 어떤 변수는 그 의도를 온전하게 담기에는 이름의 길이가 너무 길어져서, 과연 이렇게 짓는 게 맞는 건가 싶어 지기 때문이다. 아무래도 영어는 우리의 주언어가 아니기 때문에 직관성을 위해 길게 지은 이름이 오히려 더 복잡해 보이고 해석이 힘든 부작용이 생길 수 있다고 생각한다.
좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
이름 고민하느라 보내는 시간을 아까워하지 말아야겠다. 일단은 길이보다는 명확성을 더 신경 써보는 걸로. 주말이 끝나고 회사에 가면 한번 내가 짠 코드를 다시 살펴봐야겠다.
과연 내가 지은 이름은 그 의도가 명확하게 드러났을까?