더 좋은 코드를 위한 노력 - 코드 가독성 개선하기 (1)

 

 

 

위 내용은 카카오 엔터테인먼트의 FE개발팀 coze님의 <섬세한 ISFP의 코드 가독성 개선 경험>을 보고 정리한 글 입니다.

 

 

우테코 프리코스를 하면서 정말많이 힘들었던 것 중에 하나가 함수명/변수명/클래스명등  이름짓기이다. 

"의도가 분명하게 이름을 지으라" 말을 정말 쉽다.  현역 개발자들도 이름짓기가 평생의 숙제만큼 어려우니 나는 어떠하겠는가 

하지만 계속 좋은 이름을 접하고 코드리뷰를 받고 다른 코드를 보며 배워야한다.

그렇게 배우기 위해 좋은 영상이 있어서 정리를 해보았다. 

 

목차 

 

1. 정확한 단어 고르기

  1-1. 다른 뜻을 가진 단어와 구분하기    <

  1-2. 보다 구체적인 단어로 바꾸기        <

  1-3. 정확하지 않아도 좋은 경우            <

2. 잘 보이는 형태로 작성해보기

3. 정리

 

 

1. 정확한 단어 고르기

1-1. 다른 뜻을 가진 단어와 구분하기

 

 

이런 사소한 가독성 고민이 실제로 도움이 된 부분이 있었다.

 

 

사례 1

두 변수중 데이터가 없을 때 최초 한 번만 바뀌는 변수는 무엇일까?

답은 아래와 같다.

 

답은 'isLoading'이다.

Loading은 data를 싣는 행위까지 포함하기 단어이기 때문이다.

따라서 최초에 data가 없을 때는 불러오고 나서 true로 바뀌고 데이터를 불러온 이후에는 변하지 않고 계속 true의 상태를 가진다.

 

---

사례 2

username이 제도로 출력되었는지 확인하기 위해 테스트코드를 작성해 보았다.

텍스트의 존재유무를 확인하기 위해 reactTest라이브러리에서 제공하는 getBytext를 사용할 수 도 있고

queryByText함수를 사용할 수도 있다.

 

무엇이 더 적절한 사용일까?

 

차이점은 getByText는 결과가 없으면 에러를 반환하고 

queryByText는 결과가 없으면 null을 반환한다.

 

(와 이런 디테일 처음 본다.  사소한 것도 이렇게 생각해 볼 수 있구나 나도 꼭 활용해야겠다.)

이렇게 미묘한 뉘양스의 차이를 이해하여 정확한 표현으로 코드를 작성하면

가독성이 높아져 코드를 읽을 때

입체적으로다음의 시나리오가 예상이되고

문맥을 조금 더 빨리 개치할 수 있다.

 

 

---

사례 3

이 코드는 테두리 안에 과인의 이름과 이미지를 그리는 유닛이다.

다음 코드에 정확히 사용되지 않는 단어가 무엇일까?

box라는 단어는 정확하게 사용되었을까? 

 

 

웹 디자인에 따라 컴퍼넌트의 이름을 정확히 이해하려는 노력은 값어치가 있다.

예를 들어 App Bar와 GNB, LNB를 정확히 이해하거나

Card와 Box간의 차이를 정확히 이해한다면 컴포넌트 이름만 보더라도 컴포넌트의 구성을 예측할 수 있다.

 

UI 컴포넌트 라이브러리들의 정의를 살펴보면

카드는 하나의 주제로 묶인 컨텐츠와 액션 등 모든 것이며

박스는 내용물을 감싸는 래퍼의 개념에 가깝게 쓰인다.

 

(아 box는 딱 테두리만 의미라는 구나)

이렇게 내부의 컨텐츠도 포함된 경우에는 Card로 바꾸면 머릿속에 예상했던 것과 실제구현이 일치한다.

혹은 이렇게 박스를 두고 싶으면 이렇게 테투리만 구현해주면 된다.

 

---

 

이렇게 정확한 명칭을 사용해서 도움이 되었던 사례들

 

사례1

 

요청 : 회색 하이라이트를 제거해주세요

즉 마우스를 올릴때만 되도록

하지만 수정하는 작업은 무척 힘들었다.

 

수정전의 코드는 select라는 컴포넌트를 사용하고 있었다.

그런데 이 select컴포넌트와 매우 유사하게 동작하는 search라는 컴포넌트도 존재하였다.

 

select는 하나의 결과를 항상 선택한다

search는 모든 결과를 찾는 것에 그친다.

따라서 첫번째 요소가 자동으로 하이라이트되는 것은 매우 당연한 동작이었다.

 

그래서 select 컴포넌트를 search컴포넌트로 교체하는 것만으로도 이 문제는 매우 간단히 해결되었을 뿐만아니라

올바른 명칭사용으로 인해 가독성도 높아졌다.

 

 

---

 

 

1-2. 보다 구체적인 단어로 바꾸기

섬세한 ISFP의 코드 가독성 개선 경험 / if(kakao)2022

코드작성은 글쓰기와 매우 유사한 부분이 많다.

광범위한 뜻을 내포하는 단어대신에 원래의미를 잘 표현할 수 있는 단어를 사용하면 어렴풋이 이해가되는 것을 넘어서

의도나 목적을 정확히 전달해주는 효과가 있다.

 

 

다음 코드는 어떻게 개선해볼 수 있을까?

 

(일시정지하고 아래처럼 해보았다.)

if(isNotPromotionPeriodOver()){
	retrun calculateRemainTime()
}

const isPromotionPeriodOver = () => expirationTime < PROMOTION_END_TIEM;
const calculateRemainTime = () => remainTime / totalTime;

 

아하 단어를 바꾸어주었구나

왜 이 단어를 선택하셨는지 알고나니까 코드가 더 가독성이 좋아진 것 같다.

 

if(isNotPromotionDateOver()){
	retrun calculateRemainDuration()
}

const isNotPromotionDateOver = () => expirationDate < PROMOTION_END_DATE;
const calculateRemainDuration = () => remainDuration / totalDuration;

그러면 이런식으로 개선해주면 될 것 같다. 

 

 

 

 

 

---

 

 1-3. 정확하지 않아도 좋은 경우 

 

항상 정확해야할까? 

이부분은 우테코 프리코스를 하면서도 정말 많이 고민 했던 부분이다 처음에는 가독성이 좋을 것이라고 생각하고

필자또한 최대한 모든 정보를 함수이름에 넣었다. 

 pushRandomNumWithoutDuplication()

실제로 함수 길이가 이렇게 길었고 이거보다 더 길었던적도 있었다. 

다행히 피드백을 받고 지금도 지속적으로 고민하고 개선해나가고 있지만 아직 뭔가 확실한 기준이 잡히지 않았는데 마침 이렇게 다뤄주니까 정말 좋았다.

 

 

convertSecondToText는 초를 날짜단위로 변환시켜준다.

(확실히 아래가 더 가독성이 좋다.)

엄밀히 따지면 MIN HOUR DAY는 애매한 표현이다

정확한 의미는 초를 분,시,일로 환산하기 위한 값이지만 목적이 되는 단위를 전부 다 빼고 생략했기 때문이다.

하지만 이런 부정확함을 허용했을 때 전체적인 맥락이 오히려 한눈에 들어오면서 잘 읽히는 경우도 있었다.

따라서 항상 정확한 표현을 찾기보다는 문맥에 맞춰 가독성을 고민해보는 것이 효과적이었다.