네이밍, 코드 가독성
- 문맥에 대한 정보가 이미 상위 함수명에서 포함되어 있다.
- 따라서 내부 구성요소는 이를 포함하지 않아도 된다.
- 불필요한 문맥 중복은 단순히 변수명을 길어지게 만들 뿐이며, 가독성을 떨어트린다.
- 한번의 순회를 돌리기 위해서, 여러 로직임에도 욱여 넣어서 가독성과 유지보수성을 해치고 있다.
- 로직별로 분리한다면 실제 순회 횟수가 늘어나긴 하지만, cpu 입장에서 굉장히 미미한 수준의 동작이므로, 로직별로 분리해서
가독성과 유지보수 관점의 이점을 챙기는 방향이 더 좋다고 판단했다.
- 수정될 수 있는 값이며, 숫자만 있으면 코드를 이해하기 어렵다.
- 상수로 분리 후 적절한 네이밍을 달아주는게 코드 가독성과 관리에 좋다.
- 프롭명만 보고 어떤 것을 의미하는 지 대략적으로 파악이 되어야 한다.
- 그런데
AppHeader 컴포넌트에 있는 userMainHeader 라는 프롭명을 보고선, 유저 메인 헤더가 뭐야? 라는 질문밖에 떠오르지 않는다.
- 또한 실제 로직을 보니 뒤로가기 버튼 노출 여부를 결정할 뿐이므로, 기존 네이밍은 적절하지 않다.
- 네이밍 만으로 얻을 수 있는 이점이 너무 많다.
sortedData 라는 네이밍으로는 정렬된 이라는 정보 외에 유추하긴 어렵다. 좀 더 구체적인 네이밍으로 변환이 필요하다.
- 변수가 따로 선언된다면 다른 곳에서도 사용될 거라고 생각하게 되는데, 하나의 플로우 내에서만 사용된다면 코드에서도 그대로 표현해주는 것이 헷갈리지 않는다.
- 기존에는 Wrapper 터치에 대한 핸들링이 하나밖에 없어서
handlePressWrapper라는 네이밍이 허용 범위였다.
- 하지만 케이스가 늘어남에 따라,
handlePressWrapper에서 케이스가 나뉘게 된 것과 마찬가지이므로, 더 이상 이 네이밍을 사용하는 것은 적절하지 않고 수정되어야 한다.
- 공지사항을 정해진 순서대로 보여주는 기능이다.
- UserMainPopup 이라는 이름으로는 기능이 충분히 드러나지 않는다.
- 또한 기능에 대한 네이밍이 되어야지, 과한 문맥정보는 좋지 않으며, 공지사항 모달은 UserMain 외에도 다른 곳에서도 사용될 여지가 있으므로 네이밍이 적절하지 않다.
- 현재 띄우고자 하는 위치가 UserMain일 뿐이다.
기타 가독성
- 값 가공 후, 변수들을 디스트럭쳐링 한 후, setter에 그대로 넣어주고 있다.
- 불필요하게 코드 길이만 늘어나서 가독성을 해친다.
- 한 컴포넌트 내에 터치 이벤트가 여러가지 상황일 수 있다.
- 이런 경우에는
handleTouch라고 명명하면 모호해서 혼란을 준다.
- 좀 더 구체적인 내용이 네이밍에 들어가야 한다.
- 숫자를 넣어도 실제로는 secure 처리된 동그라이만 보이는 컴포넌트에 대한 네이밍 수정 건의
- 어디를 눌렀는 지 보다, 어떤 행위를 하는 건지를 정의해서 전달하는 것이 더 직관적이며 코드를 이해하기 쉽다.
- 함수명이
PressNumber라서 숫자를 누른다는 문맥은 이미 있다.
- 인자로 전달되는 것이 타입을 보면
value: string인데, value가 주는 의미가 바로 와닿지 않는다. 타입마저 number가 아니기 때문이다.
- 인자명만
number: string 으로 바꿔줘도 확실하게 의미가 와닿는다.
- 한번의 시간이 아니라, 주기적으로 리패치 하기 위한 시간 간격이므로
INTERVAL 이라는 네이밍이 더 잘 와닿는다.
- 이런 건 히스토리도 안남겨져 있고 특히나 많은 혼란을 야기할 수 있는 부분이다. 반드시 용도와 네이밍이 맞도록 수정해야 한다.
