if(kakao)2022 의 코드 가독성 세션을 글로 옮긴 것이다. 정확한 단어 고르기와 잘 보이는 형태로 쓰기 두 축으로 나눠, load 와 fetch 의 차이부터 z-index 를 목차처럼 모으기, 로그 전송 코드를 각주처럼 떼어내는 HOC 까지 실제 개선 사례를 늘어놓는다.
핵심 포인트- `loadData` 가 값을 반환하면 어색하다. load 는 가져오는 것에 더해 싣는 것까지 포함하므로 반환이 필요하면 fetch 가 맞다.
- 같은 이유로 `isFetching` 은 다시 불러올 때마다 초기화되지만 `isLoading` 은 최초 로드 이후 계속 true 로 남는 의미가 된다.
- 광범위한 단어는 구체어로 바꾼다. get → extract·parse·aggregate, number → limit·count, change → convert·filter·override, changed → dirty 식이다.
- 다만 항상 정확할 필요는 없다. `SECOND_TO_MINUTE` 같은 엄밀히 부정확한 표현이 문맥에서 더 잘 읽히는 경우가 있다.
- 조건 분기가 순차적으로 읽어야 결과를 알 수 있다면 플로우차트를 표로 바꾸듯, 코드도 행과 열이 드러나는 형태로 고치면 인과관계가 한눈에 들어온다.
상세 정리- 전제: 개발 초기 비용보다 유지보수 비용이 기하급수적으로 커지고 협업은 필수이므로, 두 문제의 핵심에 가독성이 있다는 데서 출발한다. 구글이 '가독성 승인' 이라는 별도 리뷰 절차를 두는 사례를 근거로 든다.
- 발표 형식: 자신의 MBTI(ISFP) 중 스스로와 비슷하다고 느낀 특징에 빗대 사례를 배치했고, 모든 ISFP 가 그렇다는 뜻이 아니라는 단서를 붙인다.
- 컴포넌트 이름 사례: 사과 이름·이미지·텍스트를 모두 담은 컴포넌트를 `Box` 라 부르는 것은 부정확하다. Box 는 감싸는 외곽 요소를 가리키는 용어이고, 한 주제로 묶인 콘텐츠와 액션 전체는 `Card` 가 맞다.
- 구체어 치환 사례: 시간을 뜻하는 모호한 단어를 시각·기간이 드러나는 단어로 바꾸니, if 문에서는 비교 가능한 값이라는 점이, return 에서는 나눌 수 있는 정량값이라는 점이 각각 드러났다.
- 비유로 '짜증 난다' 를 서운하다·억울하다로 바꾸는 것을 든다. 감정 표현이든 코드든 구체어가 상황을 더 정확히 전달한다는 논지다.
- 표처럼 쓰기 ①: 두 개의 불리언 조건에 따른 결과를 순차적으로 따라가야 하는 코드를, 행·열 대응이 보이는 형태로 바꿔 인과관계를 드러낸다.
- 표처럼 쓰기 ②: if-else 로 '사과·바나나·포도' 를 할당하던 코드를 맵으로 바꾸면 key 와 value 가 일직선에 놓여 대응 관계가 눈에 들어온다.
- 목차처럼 쓰기: 앱 곳곳에 흩어진 `z-index` 는 어떤 요소에 무슨 값이 걸렸는지 파악하기 어렵고, 모르고 새 값을 넣었다가 요소가 가려지는 사고가 난다. 한곳에 모아 두면 책의 목차처럼 전체를 조망할 수 있다.
- 용어 정리처럼 쓰기: 조건문에 `shouldDisplay` 같은 이름을 붙여 무엇을 판단하는지 밝히고, data 가 food 를 뜻한다는 것과 5000 이라는 숫자가 건강하지 못한 정도의 척도라는 의도를 코드 안에 표식으로 남긴다. 코드는 길어져도 의도가 명확해진다.
- 각주처럼 쓰기: 소설·챕터를 그리는 코드에서 핵심은 렌더링이고 클릭 로그 전송은 부차적이다. 그런데 로그 코드가 중간에 부피를 차지한다.
- 해결: 클릭 이벤트를 모아 처리하는 HOC 를 만들어 애플리케이션 최상단에 두고, DOM 에 `data-click-log` 어트리뷰트가 있으면 로그를 보내도록 이벤트 전파를 활용했다. 본문에는 각주의 위 첨자처럼 어트리뷰트만 남는다.
- 저자는 가독성 고민이 겉으로 드러나지 않아 투자한 시간에 회의감이 들 때가 있었지만 돌이켜 보면 가치가 있었다고 정리한다.
왜 읽나변수·함수 이름을 두고 매번 오래 고민하는 개발자에게, 그 고민을 구조화할 수 있는 네 가지 형태(표·목차·용어·각주)와 단어 치환표를 준다.
카카오 엔터테인먼트 FE·
NHN Cloud·
Stack Overflow Blog·
포스타입·