DAY05

  • 오늘 읽은 범위 : 의미 있는 이름 ~p38

책에서 기억하고 싶은 내용을 써보세요

  • 이전 페이지로부터 계속
  • 자신의 기억력을 자랑하지 마라
    • 코드를 독해할 때 독자가 자신이 아는 이름으로 이름을 변환해야 한다면 그 이름은 일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문이다.
    • 똑똑한 프로그래머-자기 자신을 과시하고 싶어하는 프로그래머-와 전문가 프로그래머의 차이점은, 전문가 프로그래머는 명료함이 최고라는 사실을 이해함에 있다
      • 전문가 프로그래머는 자신의 능력을 남들이 이해하는, 좋은 방향으로 코드를 짠다
  • 클래스 이름
    • 클래스/객체 이름은 명사나 명사구가 적합하다
      • 좋은 예시: Customer, WikiPage, Account, AddressParser 등
      • 피해야 할 단어: Manager, Processor, Data, Info
      • 금기어: 동사
  • 메서드 이름
    • 메서드/함수 이름은 동사나 동사구가 적합하다
      • 좋은 예시: postPayment, deletePage, save 등
      • 접근자, 변경자, 조건자는 앞에 get, set, is를 붙힌다 (getAccountId() 등)
  • 기발한 이름은 피하라
    • 재미난 이름보다는 명료한 이름을 선택한다 
        HolyHandGrenade    // 무엇을 하는 함수인지 알 수 없다
  DeleteItems        // 명료한 함수명
    • 특정 문화에 치우치거나, 재치를 발휘할 필요가 없다. -기발한 이름은 그 기발함을 기억하는 동안만 이름을 기억한다!-
    • 의도를 분명하고 솔직하게 표현해라!
  • 한 개념에 한 단어를 사용하라
    • 추상적인 개념 하나 = 단어 하나!
      • 같은 개념의 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란을 야기한다!
      • 같은 개념이라면 단어에 일관성을 유지해야 한다
      • 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다!
  • 말장난을 하지 마라
    • 한 단어에 두가지 개념을 사용하지 마라
    • add, append, insert 등 비슷한 단어지만 다른 개념에는 다른 단어를 사용해야 한다.
      • add => 다른 두 값을 더할 때 사용
      • insert/append => 집합에 값을 하나 추가할 때 사용
  • 해법 영역에서 가져온 이름을 사용하라
    • 모든 이름을 문제영역domain에서 가져오는 정책은 현명하지 못하다-코드를 읽을 사람은 프로그래머이므로, 전산 용어, 알고리즘 이름, 패터 이름, 수학 용어 등을 사용해도 무방하다-
    • 기술 개념에는 기술 이름이 가장 적합한 선택이다
  • 문제 영역에서 가져온 이름을 사용하라
    • 앞서 말한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져온다. -필요하다면 전문가에게 의미를 물어 파악할 수 있다-
    • 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가지고 오는 것이 현명하다
  • 의미 있는 맥락을 추가하라
    • 스스로 의미가 분명한 이름 > 클래스, 함수, 이름 공간Name space에 넣어 맥락을 부여 > 앞의 모든 방법이 실패한다면 접두어를 사용
    • 주소를 예를 들어보자:
      • firstName, lastName, street, houseNumber, city, state, zipcode라는 변수들이 있을 때, 만약 state라는 변수 하나만 가지고 맥락을 파악할 수 있을까?
        • 이럴 때 접두어를 붙혀 맥락을 분명하게 만들어보자 -addrFirstName, …1
      • 각 클래스, 함수, 변수들의 맥락을 분명하게 하기 위해 이름을 변경하고, 클래스를 쪼개서 함수들을 분리해라
  • 불필요한 맥락을 없애라
    • 일반적으로-의미가 분명한 경우에 한해서- 짧은 이름이 긴 이름보다 좋다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

  1. 프로그래머는 코드를 이해하기 쉽게 짜야한다. 집중적인 탐구가 필요한 코드가 아니다. 적어도 이 챕터가 하고자 하는 모든 말을 여기에 함축해서 담아둔 구절인 것 같습니다. 프로그래머라면 우리가 알아볼 수 있어야 하지만, 우리 코드를 읽는 독자들-동료 프로그래머들-이 잘 이해하고 맥락에 맞으며 무릎을 탁! 치며 알아볼 수 있는 코드를 짜야함을 이 챕터에서 알려줍니다.
  2. 많은 구절에서 우리는 전문가임을 이 책에서는 강조합니다. 우리는 일을 함에 있어서는 재미로 코딩을 하는 것이 아니며, 기발하거나 지독한 창의성을 발휘하여 이름짓는 것을 금기합니다. 이것은 우리가 이해할 수 있는 코드를 쓰는데 방해만 될 뿐이며, 똑똑할 수는 있어도, 전문가 답지 않은 행동이라 얘기합니다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요

  • -

세줄 요약

  • 좋은 이름을 선택하려면 설명능력이 뛰어나야 하고 문화적인 배경이 같아야 한다
  • 프로그래머는 문장이나 문단처럼 읽히지는 않더라도 적어도 표나 자료구조처럼 읽히는 코드를 짜는데 집중해야 한다
  • 소개했던 규칙 몇가지를 적용해 코드 가독성이 높아지는지 살펴보라

  1. 물론 Address라는 클래스를 생성하여 변수가 좀 더 큰 개념에 속한다는 사실을 알려줄 수도 있다. p35 ↩