8장 오혜성

8장/오혜성.md

@@ -0,0 +1,59 @@
+# 명명을 잘하는 방법
+* 이름은 문서화의 가장 쉬운 형태
+  + 서로 다른 장소에서 정보를 종합하면 인지 부하가 증가함
+  + 마찬가지로 문서를 읽기 위해 코드 외부로 이동하는 것을 프로그래머들은 피하고 싶어함
+  + 따라서 가장 많이 읽는 문서는 주석과 이름임
+  > '코드 외부'가 요즘에는 ide이지 않나 싶음. 그래서 요즘 앵간해서는 ide 내부의 ai 도구들에게 많이 물어보는듯
+
+* 초기 명명 관행이 지속적으로 영향을 미침
+  + 요즘 만들어진 코드들이 사전에 등재된 단어로 구성되고, 변수 이름 내에서 단어를 분할함 (더 잘 지음)
+  + 코드베이스를 시간이 지남에 따라 어떻게 바뀌나도 관찰했음
+    - 시간이 지난다고 해도 명명 규약이 개선되지는 않음
+    - 프로젝트 초기 단계에서 이름을 만드는 방식이 그 이후로도 사용될 가능성이 높으니 초기에 주의를 기울여야함
+
+* 이름 품질 평가 시기
+  + 코드를 작성할 때는 이미 인지 부하가 된 상태라 품질 높은 이름을 생각하지 못할 수 있음
+  + 코딩 이외의 시간에 품질을 숙고하는 게 좋은데, 코드 리뷰가 좋은 기회임
+
+* 코드 리뷰시 이름에 대해
+  + 코드에 대해 아무것도 모르는 상태에서, 이름이 무엇을 의미하는지 명확한가? 예를 들어 이 이름이 구성하는 단어의 의미를 알겠는가?
+  + 이름이 모호하거나 불명확한가?
+  + 혼란을 줄 수 있는 약어를 사용하는가?
+  + 어떤 이름들이 서로 비슷한가? 이 이름들은 서로 비슷한 것들을 가리키는가?
+
+## 어떤 종류의 이름이 더 이해하기 쉬운가?
+
+* 코드를 이해하고 버그를 쉽게 찾기 위해서라면 명확한 단어를, 
+  + 기억을 잘하기 위해서라면 간결한 약자를 사용하면 좋다
+  + 좋은 변수 이름을 명명하기 위해서는 이 둘 사이의 균형이 필요
+
+* 스네이크 케이스 vs 카멜 케이스
+  + 카멜 케이스가 연구 결과 더 높은 정확도를 갖지만 인식하는데 시간이 더 걸렸음
+  + 일관성 또한 중요한 측면이기 때문에 코드 베이스의 케이스들을 카멜 케이스로 변경하는 것은 현명하지 않다 생각
+
+## 이름이 버그에 미치는 영향
+
+* 나쁜 이름을 가진 코드에 버그가 더 많다
+  + 명명 문제와 코드 품질 사이에 통계적으로 유의미한 연관성이 있다
+  + 잘못된 명명 방식은 단지 읽고 이해하고 유지 보수하기 어려운 코드가 아니라 잘못된 코드일 가능성이 높다
+
+* 잘못된 이름 문제를 해결하는 것이 반드시 버그를 고치거나 예방하진 않지만
+  + 찾는 과정에서 코드를 개선하고 버그 발생 가능성이 있는 위치를 찾는 데 도움이 될 수 있음
+  + 즉 이름을 개선하면서 간접적으로 버그가 줄고, 더 나은 이름을 사용하는 코드는 이해하기 쉽기 떄문에 수정 시간이 단축됨
+
+## 더 나은 변수명
+
+* 이름을 선택할 때 고려해야 할 주요 사항은 이름의 의도
+  + 개체가 어떤 정보를 보유하고 있는지
+  + 무엇을 위해 사용되는지
+
+> 이름의 일관성에 대해서
+> 일반적으로 개발을 동시에 시작하는데요.. 예를 들어 '정책'을 보여주는 서비스를 만들 때
+> 라우트, 파일, 디렉터리 들을 'policy'로 만들었는데
+> 이후 서버에서는 다른 단어를 사용할 때 ....
+> 정말 고통스럽습니다 🤣 
+> api 레이어에서만 서버에서 사용하는 단어를 사용하고, 기존 작성된 것을 유지하자니 일관성이 떨어져 헷갈리고 ..
+> 수정하자니 귀찮고 ..... 라고 적지만 요즘엔 ai한테 부탁하면 간단하겠네요
+> > 근데 더 문제가 되는건 서비스되고 나서 맞춰야될때 ... 기존 라우트에서 리다이렉트 시켜줘야하니 .. 급 주절주절
+
+