TIL (Today I Learned)
2022.02.21
오늘 읽은 범위
2장. 의미 있는 이름
책에서 기억하고 싶은 내용을 써보세요.
- 프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 실제 List가 아니라면 List라 명명하지 않는다. 프로그래머에게 List라는 단어는 특수한 의미다. (p.23)
- 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다. (p.26)
- 이름 길이는 범위 크기에 비례해야 한다. (p.28)
- 클래스나 객체의 이름에서 Manager, Processor, Data, Info 등과 같은 단어는 피하고 동사는 사용하지 않는다. (p.32)
- javabean 표준을 따르면 접근자, 변경자, 조건자는 앞에 get, set, is를 붙인다. (p.32)
- 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 예를 들어, 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다. (p.33)
- 한 단어를 두 가지 목적으로 사용하지 마라. (p.34)
- 다른 방법으로 명확한 표현에 한계가 있다면 접두어를 추가하는 것도 최후의 방법으로 활용해볼 수 있다. (p.35) - ex. 주소를 다루는 경우 state -> addrState
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- 클린코딩에 관련된 노력을 시작하면서 가장 즉각적으로 도움이 되었던 챕터이다. 특히 추상적 개념의 표현과 관련해서 나는 서로 다른 표현을 종종 활용하는 안 좋은 습관을 가지고 있었다. 지금은 꼭 코드를 읽는 사람이 알아야 하는 차이가 아니라면 최대한 용어를 통일하려고 한다. 특정 함수가 어떠한 기능을 구체적으로 어떻게 실행하는지에 대한 영역은 프로그래머가 무조건적으로 알아야되는 부분이 아니기 때문이다. 함수는 무엇을 받아서 무슨 일을 하는지만 알려주면 된다. 그 외적인 정보는 누설할 필요가 없다. 한 예시로 지금은 외부 API와 통신이 필요한 경우 fetch라는 이름을 사용하고 그 외 프로그램 내부적으로 데이터를 처리하는 경우 get이라는 이름을 사용하고 있다. 사실 이 부분도 get으로 모두 통일하는 것이 맞을지 아니면 지금처럼 최소한의 구분점은 두는 것이 맞을지 잘 모르겠다. 매번 느끼지만 더 많은 고민과 시간이 필요할 것 같고 새로운 사람들과 일할 때 그 사람들과의 답을 빠르게 찾아가는 것이 중요할 것 같다.
'독서 > 클린코드' 카테고리의 다른 글
[클린코드] 2022-03-01 TIL (0) | 2022.03.02 |
---|---|
[클린코드] 2022-02-28 TIL (0) | 2022.03.01 |
[클린코드] 2022-02-25 TIL (0) | 2022.02.26 |
[클린코드] 2022-02-22 TIL (0) | 2022.02.22 |
[클린코드] 2022-02-20 TIL (0) | 2022.02.20 |