TIL (2022.02.20)

2022.02.20

오늘 읽은 범위

2장. 의미있는 이름

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

• 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다. _p25

• 이런 관점에서 긴 이름이 짧은 이름보다 좋다. 검색하기 쉬운 이름이 상수보다 좋다. 개인적으로는 간단한 메서드에서 로컬 변수만 한 문자를 사용한다. 이름 길이는 범위 크기에 비례해야 한다 _p28

• 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다. _30-31p

• 마찬가지로, 동일 코드 기반에 controller, manager, driver를 섞어 쓰면 혼란스럽다. DeviceManager와 ProtocolController는 근본적으로 어떻게 다른가? 어째서 둘 다 Controller가 아닌가? 어째서 둘 다 Manager가 아닌가? 정말 둘 다 Driver가 아닌가? 이름이 다르면 독자는 당연히 클래스도 다르고 타입도 다르리라 생각한다. / 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다. _33p

• 프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다. 의미를 해독할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 저자에게 있는 잡지 모델이 바람직하다. _34p

• 어느 메서드가 state라는 변수 하나만 사용한다면? 변수 state가 주소 일부라는 사실을 금방 알아챌까? / addr라는 접두어를 추가해 addrFirstName, addrLastName, addrState라 쓰면 맥락이 좀 더 분명해진다. 물론 Address라는 클래스를 생성하면 더 좋다. 그러면 변수가 좀 더 큰 개념에 속한다는 사실이 컴파일러에게도 분명해진다. _35p

• 암기는 요즘 나오는 도구에게 맡기고, 우리는 문장이나 문단처럼 읽히는 코드 아니면 (정보를 표시하는 최선의 방법이 항상 문장만은 아니므로) 적어도 표나 자료 구조처럼 읽히는 코드를 짜는 데만 집중해야 마땅하다. _38p

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

• 이름을 짓는데 고심을 많이 하는 편이었지만, 항상 아는 단어에서 남들에게 이 ‘단어'가 어떻게 보일지 약간의 허영을 담은 이름짓기 식이었다는 생각이 든다. 마지막 문단에 ‘좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다.’라는 설명이 정말 많이 와닿았다. 영어 문화권이 아닌 우리 개발자들은 좀 더 엄격하고 정형화된 이름짓기 훈련이 필요할 것 같다.

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

• MAX_CLASSES_PER_STUDENT는 grep으로 찾기 쉽지만~ _p28 → grep은 리눅스에서 가장 많이 사용되는 명령어 중 하나인 ‘입력으로 전달된 파일의 내용에서 특정 문자열을 찾고자할 때 사용하는 명령어’

• 인코딩을 피하라, ~ 인코딩한 이름? _p29 → 여기서 말하는 인코딩의 개념은??

• ‘해법 영역에서 가져온 이름을 사용하라’, ‘문제 영역에서 가져온 이름을 사용하라’