[노개북 1기] TIL (2022.01.25)

yourjin·2022년 2월 26일
0

read.log

목록 보기
6/37
post-thumbnail

TIL (2022.01.25)

DAY 5

🔖 오늘 읽은 범위 : 2장, 의미 있는 이름(~ p.38 마치면서)


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

  • 기발한 이름은 피하라
    • 재미난 이름보다 명료한 이름을 선택하라.
  • 한 개념에 한 단어를 사용하라
    • 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 예를 들어,똑같은 메서드를 클래스 마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.
  • 말 장난을 하지 마라
    • 한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.
      • 예를 들어, 지금까지 구현한 add 메서드는 모두가 기존값 두 개를 더하거나 이어서 새로운 값을 만든다고 가정하자. 새로 작성하는 메서드는 집합에 값 하나를 추가한다. 이 메서드를 add라 불러도 괜찮을까?
      • 하지만 새 메서드는 기존 add 메서드와 맥락이 다르다. 그러므로 insert나 append라는 이름이 적당하다. 새 메서드를 add라 부른다면 이는 말장난이다.
    • 프로그래머는 코드를 최대한 이해하기 쉽게 짜야한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다.
  • 해법 영역에서 가져온 이름을 사용하라
    • 코드를 읽을 사람도 프로그래머라는 사실을 명심한다. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다. 모든 이름을 문제 영역(domain)에서 가져오는 정책은 현명하지 못하다.
  • 문제 영역에서 가져온 이름을 사용하라
    • 적절한 ‘프로그래머 용어’가 없다면 문제 영역에서 이름을 가져온다. 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있다.
  • 의미 있는 맥락을 추가하라
    • 그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.
  • 불필요한 맥락을 없애라
    • 일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다.
      • accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나 클래스 이름으로는 적합하지 못하다.
      • Address는 클래스 이름에 적합하다. 포트 주소, MAC 주소, 웹 주소를 구분해야 한다면, PostalAddress, MAC, URI라는 이름도 괜찮겠다.
  • 마치면서
    • 좋은 이름을 선택하는 능력은 기술, 비즈니스, 관리 문제가 아니라 교육 문제다.
    • 여느 코드 개선 노력과 마찬가지로 이름 역시 나름대로 바꿨다가는 누군가 질책할지도 모른다. 그렇다고 코드를 개선하려는 노력을 중단해서는 안 된다.

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

  • 지난번에 이어서 “의미 있는 이름”을 짓기 위한 규칙들을 배우면서, 이름을 잘 짓는 것(수정하는 것) 만큼 간단하면서 큰 효과를 가져오는 것이 없다는 생각이 들었다. 1장에서는 프로그래머로서 장인 정신과 이를 체득 과정이 필요하다는 걸 배웠다. 이는 그러한 ‘감각’을 익히는 것은 쉽지 않다는 뜻이기도 하다. 하지만 좋은 이름을 짓는 일은 다르다. 내가 이해하기 쉽고, 내 옆 사람이 이해하기 쉽다면 대부분이 이해하기 쉽다. 조금만 신경을 쓰면 되지만, 그만큼 간과하기 쉽기에 이번 기회에 다시 한번 짚고 넘어갈 수 있어서 좋았다.

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

궁금한 내용은 아니지만, 2장에서 배운 규칙들을 잊지 않기 위해 정리해보려고 한다.

  • 의도를 분명히 밝혀라 (→ 어떤 기능을 하기 위해 있는지(정보)를 이름에 명시하라)
  • 그릇된 정보를 피하라 (→ 오해의 소지가 있는 단어는 피하라)
  • 의미 있게 구분하라 (→ 이름이 다르다면 의미도 달라져야 한다)
  • 발음하기 쉬운 이름을 사용하라
  • 검색하기 쉬운 이름을 사용하라
  • 인코딩을 피하라 (→ 해석하기 어려운 축약어 등을 피하라)
  • 자신의 기억력을 자랑하지 마라 (→ 나만의 의미를 가지는 변수를 피하라)
  • 기발한 이름은 피하라
  • 한 개념에 한 단어를 사용하라
  • 말 장난을 하지마라 (→ 다른 개념에 같은 단어를 사용하지 마라)
  • 해법 영역에서 가져온 이름을 사용하라 (→ 프로그래머가 사용하는 용어를 따오자)
  • 문제 영역에서 가져온 이름을 사용하라 (→ 도메인에서 사용하는 용어를 따오자)
  • 의미 있는 맥락을 추가하라 (→ 클래스, 함수, 변수 등을 통해 맥락 있게 파악할 수 있게 하자)
  • 불필요한 맥락을 없애라 (→ 불필요한 중복은 제거하자)

소감 3줄 요약

  • 프로그래머는 코드를 최대한 이해하기 쉽게 짜야한다.
  • 재미난 이름보다 명료한 이름을 선택하라.
  • 누군가의 질책이 두려워 이름을 개선하려는 노력을 멈춰서는 안된다.
profile
make it mine, make it yours

0개의 댓글