😄 책에서 기억하고 싶은 내용을 써보세요.
이 장에서는 이름을 잘 짓는 간단한 규칙을 몇가지 소개한다.(p.22)
결코 간단하지 않은 걸요? 😵
- 의도를 분명히 밝혀라(p.22)
- 그릇된 정보를 피하라(p.24)
- 의미 있게 구분하라(p.25)
- 발음하기 쉬운 이름을 사용하라(p.27)
- 검색하기 쉬운 이름을 사용하라(p.28)
- 인코딩을 피하라(p.29)
- 자신의 기억력을 자랑하지 마라(p.31)
똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.
- 클래스 이름과 객체 이름은 명사나 명사구가 적합하다.(p.32)
- 메서드 이름은 동사나 동사구가 적합하다(p.32)
- 기발한 이름은 피하라(p.32)
- 한 개념에 한 단어를 사용하라(p.33)
- 말장난을 하지 마라(p.34)
- 한 단어를 두 가지 목적으로 사용하지 마라.
- 해법 영역에서 가져온 이름을 사용하라(p.34)
- 기술 개념에는 기술 이름이 가장 적합한 선택이다.
- 문제 영역에서 가져온 이름을 사용하라(p.34)
- 문제 영역(도메인) 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.
- 의미 있는 맥락을 추가하라(p.35)
- 필요하다면 메서드를 분리해서 그 의미를 분명히 한다.
- 불필요한 맥락을 없애라(p.37)
- 일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다.
🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- 얼마나 많은 var, a, b, vo, list, map 등등을 보았었던가.
- 네이밍컨벤션(Naming convention)이 중요함을 익히 알고 있지만, 돌아는 가잖아요 이유로 허용 했던 예외적인 상황이 얼마나 많았던가
- 그 코드를 보는 내 머리가 돌아버리겠다 😱
- 사소하지만 결코 사소하지 않은 네이밍 컨벤션
- 혼자 개발 할것이 아니라면(혼자 개발하더라도 남에게 코드를 보여줄거라면) 반드시 지켜야 할 큰 원칙
🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
-
창피하지만 아래 개념을 설명할 수 없어서 정리해보았다
-
visitor 패턴
- 방문자와 방문 공간을 분리하여, 방문 공간이 방문자를 맞이할 때, 이후에 대한 행동을 방문자에게 위임하는 패턴
- Visitor - ConcreteVisitor(인터페이스-implement 관계), Element - ConcreteElement, ObjectStruture
- 아래 예시(회원 등급(Element)별 제공하는 혜택(Visitor))로 이해 하자
- 방문자 패턴, codinglog
- 회원 등급별 제공할 혜택 : visitor, 예시에선 Benefif
- 회원 등급별 제공할 혜택의 종류 : ConcreteVisitor, 예시에선 [PoingBenefit, DiscountBenefit]
- visitor가 방문해 수행할 대상, 여기선 혜택정보를 가져오는 행위 : Element, 예시에선 Member
- 회원 등급별 제공할 혜택을 가져오는 메소드 :
accept(), 예시에선getBenefit() - Element의 구현체 : ConcreteElement, 예시에선 [VipMember, GoldMember]
-
jobQueue
- 개별적으로 실행되는 스크립트 블럭을 하나의 잡(job)
- 이러한 잡을 관리하는 queue를 jobQueue라고 함
😎 소감 세줄 요약
- 네이밍 컨벤션의 타협은 no more 👊
- 오늘 확인된 규칙을 기반으로 동료개발자들과 네이밍 컨벤션에 대해 재정립 및 적용에 대해 이야기 해볼 필요가 있음. 🤝
- 다시 한번 확인된 사소한 곳에서 발견되는 정직은 결코 사소하지 않다.