TIL (Today I Learned)
2024.03.03
🔖 오늘 읽은 범위
2장. 의미있는 이름
💡 책에서 기억하고 싶은 내용
의도를 분명히 밝혀라
"의도가 분명하게 이름을 지으라"고 말하기는 쉽다.
여기서는 의도가 분명한 이름이 정말로 중요하다는 사실을 거듭 강조한다.
좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
그러므로 이름을 주의깊게 살펴 더 나은 이름이 떠오르면 개선하기 바란다.
그러면 (자신을 포함해) 코드를 읽는 사람이 좀 더 행복해지리라.
변수나 함수 그리고 클래스 이름은 존재 이유, 수행 기능, 사용 방법과 같은 굵직한 질문에 모두 답해야한다. 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. - p.22
의미 있게 구분하라
a나 the와 같은 접두어를 사용하지 말라는 소리가 아니다. 의미가 분명히 다르다면 사용해도 무방하다.
예를 들어, 모든 지역 변수는 a를 사용하고 모든 함수 인수는 the를 사용해도 되겠다.
요지는 zork라는 변수가 있다는 이유만으로 theZork라 이름 지어서는 안 된다는 말이다. - p.26
발음하기 쉬운 이름을 사용하라
발음하기 쉬운 이름은 중요하다.
프로그래밍은 사회 활동이기 때문이다. - p.27
검색하기 쉬운 이름을 사용하라
간단한 메서드에서 로컬 변수만 한 문자를 사용한다.
이름 길이는 범위 크기에 비례해야한다.
변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다. - p.28
자신의 기억력을 자랑하지 마라
똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다.
전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다. - p.31
클래스 이름
클래스 이름과 객체 이름은 명사나 명사구가 적합하다.
Customer, WikiPage, Account, AddressParser 등이 좋은 예다.
Manager, Processor, Data, Info 등과 같은 단어는 피하고, 동사는 사용하지 않는다. - p.32
메서드 이름
메서드 이름은 동사나 동사구가 적합하다.
postPayment, deletePage, save 등이 좋은 예다.
접근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.
생성자를 중복정의할 때는 정적 팩토리 메서드를 사용한다. 메서드는 인수를 설명하는 이름을 사용한다. - p.32
⭕️ Complex fulcrumPoint = Complex.FromRealNumber(23.0);❌ Complex fulcrumPoint = new Complex(23.0);
한 개념에 한 단어를 사용하라
메서드 이름은 독자적이고 일관적이어야 한다.
일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다. - p.33
말장난을 하지 마라
한 단어를 두 가지 목적으로 사용하지 마라.
다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.
프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다.
집중적인 탐구가 필요한 코드가 아닌 대충 훑어봐도 이해할 코드 작성이 목표다.
불필요한 맥락을 없애라
일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다.
이름에 불필요한 맥락을 추가하지 않도록 주의한다.
마치면서
암기는 요즘 나오는 도구에게 맡기고, 우리는 문장이나 문단처럼 읽히는 코드 아니면 적어도 표나 자료 구조처럼 읽히는 코드를 짜는 데만 집중해야 마땅하다.
여느 코드 개선 노력과 마찬가지로 이름 역시 나름대로 바꿨다가는 누군가 질책할지도 모른다.
그렇다고 코드를 개선하려는 노력을 중단해서는 안 된다.
다른 사람이 짠 코드를 손본다면 리팩터링 도구를 사용해 문제 해결 목적으로 이름을 개선하라.
단기적인 효과는 물론 장기적인 이익도 보장한다.
✏️ 오늘 읽은 소감
2장에서는 좋은 이름을 짓는 방법에 대해 소개하고 있다.
책에서도 기발한 이름은 피하라고 하듯이, 역시 좋은 네이밍은 창조가 아니라 조합에서부터 시작되는 것 같다.
읽으면서 개발을 처음 배울 때 이름을 a,b,c 이런 식으로 지었던 내 모습이 생각나서 웃음이 나기도 했다.
한편으로는 현업에서 개발할 때나 코드리뷰를 할 때 명명 지적을 받았던 기억이 새록새록 나기도 했다.
‘주석도 달아놨고, 내가 알아볼 수 있으니까 다른 사람들도 알아볼 수 있겠지?"’라는 안일한 생각에서 출발한 결과물이었고, 협업을 원활하게 하기 위해서는 시간이 좀 더 걸리더라도 좋은 이름 짓기에 신경쓰고 의미를 분명히 전달하는 것이 중요하다는 것을 깨달은 계기였다.
그렇지만 책에서 말하는 명명 규칙이 무조건 답은 아니라고 생각하며 개발팀마다 좋은 네이밍에 대한 정의가 다 다를 것이고, 함께 일할 때는 팀 내에서 개발자들이 함께 맞춰나간 컨벤션을 따르는 것이 맞다고 생각한다.
나의 의도가 잘 드러나는, 처음 보는 사람도 쉽게 읽을 수 있는 코드를 작성하는 날이 얼른 오길 바란다.
명명 지적을 두려워하지 말자.
🤔 궁금한 내용이나 잘 이해되지 않는 내용
클래스 이름을 지을 때 Manager, Processor, Data, Info을 피해야하는 구체적인 이유
혼자서 프로젝트를 하더라도 명명 규칙을 정해서 작성하는 습관 들이기
❓ 이 책을 읽으려는 이유
