[DEVLOG] if(kakao) dev 2022 개발자 컨퍼런스 후기 - 1. ISFP의 코드 가독성 개선 경험

 

본 포스트는 카카오 컨퍼런스 if(kakao) dev 2022 컨퍼런스 내용 및 자료가 포함되어 있습니다.
혹여나 권리 관련 문제가 발생한다면, 글 수정 / 삭제를 진행하도록 하겠습니다. 

 

 

🏝 0. 유튜브 다시보기 영상

https://www.youtube.com/watch?v=emGLxi0LvNI&list=LL&index=46&t=165s

 

 

🤔 1. 코드 가독성 개선 경험

 

일반적인 리팩토링은, 기존의 로직은 변함 없이 코드의 구조 혹은 가독성을 높이는 작업입니다.

중복코드를 제거하거나, 긴 서브루틴을 쪼개는 작업, 여러가지를 수행하는 함수에서 역할의 분리, 전역변수 설정, 올바르지 않은 네이밍 수정, 사용하지 않는 코드 제거 등이 일반적인 리팩토링을 의미한다고 합니다.

 

하지만 카카오의 coze 개발자님은, 자신의 코드가 다른 사람들에게 쉽게 이해가 가도록 많은 노력을 하셨습니다.

일반적인 리팩토링의 범주에서 확장하여, "남들에게 쉽게 이해되도록 할 수 없을까?"하는 고민을 포함하여 리팩토링을 진행하셨습니다.

처음에는 이러한 작고 세심한 고민이 쓸데 없는 시간을 낭비한 것은 아닌지 우려하셨지만, 돌이켜 보면 유지보수 면에서 굉장히 도움이 많이 되었다고 합니다. 

 

"남들에게 쉽게 이해되도록 할 수 없을까?"라는 스스로에 대한 질문을 통해 코드 가독성을 개선한 경험은 크게 두 가지로 나뉘어진다고 합니다.

1) 정확한 단어를 고르기
2) 잘 보이는 형태로 작성하기 

 

 

1-1. 정확한 단어 고르기

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

 

const data = await loadData();

이 코드라인은 언뜻 보았을 때 크게 문제가 없어 보입니다. 함수 이름을 통해서 데이터를 불러온다는 것도 알 수 있고, 해당 리턴 값으로 데이터를 받아올 수 있다는 것도 알 수 있습니다.

 

그러나 coze님은, 세세한 디테일로부터 해당 함수의 정확한 역할을 명시하려고 노력하셨습니다.

load : 가져와서 싣다
fetch : 가져오다

 

load는 이미 특정 공간에 싣는 것까지 완결된 경우를 의미합니다. 즉 loadData()라는 함수 내부에서는, 특정 데이터를 가져온 후에 특정 공간에 싣고 난 것까지 포함한다는 것입니다.

만약 const data = await loadData(); 라고 하면, loadData에서 데이터를 특정 공간에 한 번 싣고, const data 부분에 한 번 더 싣는, "역전 앞"과 같은 느낌을 받았다고 합니다.

 

 그래서 const data = await fetchData();로 변경하면, fetchData() 함수는 단순히 데이터를 "불러온다"의 역할을 명시하고, const Data에 저장함으로써 fetchData 함수의 역할을 정확하게 표현할 수 있었습니다.

 

다른 방법도 있습니다.

const success = await loadData();

 

loadData() 메서드를 통해, 데이터를 가져온 후에 특정 공간에 싣는 것까지 완결한 상태임을 알 수 있습니다.

그 이후에 성공 여부에 대해서만 리턴받는 것도 좋은 가독성 있는 코드라고 설명하셨습니다.

 

또 다른 사례를 한 번 살펴봅시다.

" 데이터를 가져올 때 get이 좋을까요? query가 좋을까요? "

 

개인적으로 get이라는 prefix를 사용해서 많은 함수를 만들어 왔던 저에게는 굉장히 혼란스러웠던 질문이었습니다.

데이터를 가져오면, 당연히 get이 맞는거 아닐까? 라고 단순히 생각했었으나, coze님은 아래와 같은 의미로 접근하셨습니다.

 

get : 가져오다, 결과를 당연히 가져올 것으로 기대합니다!
query : 질문하다, 결과가 있는지 질문하는 것이므로, 결과가 없을 수도 있습니다.

이러한 단어의 뉘앙스는 결과에도 영향을 미칩니다.

get은 결과를 당연히 가져올 것으로 기대하기 때문에, 불러올 값이 null이라면, Error가 발생하는 것이 옳다고 합니다.

query와 같은 경우에는 결과가 없을 수도 있으므로, 이 경우에는 null을 갖게 되는 것이죠.

 

따라서 단순히 결과가 있을지 확인하고 싶을때는 get보다 query를 사용하는 것이 더욱 적합했다고 합니다. 

또한 get 같은 경우에는, 가져온 뒤 대상을 추가적인 활용하기를 기대한다고 합니다. 

대상을 가져온 후 대상을 활용하려는 경우에는 get을 사용하는 것이 좋습니다.

 

 

프론트엔드에서 UI 컴포넌트와 관련해서 서치바 하단 연관 검색어 부분에서 한 원소가 HighLight되는 현상을 제거하실 때에도 단어 구별을 통해 문제를 해결할 수 있었다고 합니다.

https://speakerdeck.com/kakao/seomsehan-isfpyi-kodeu-gadogseong-gaeseon-gyeongheom

 

기존에는 select를 사용하고 있었기 때문에, highlight되는 것은 당연한 것이었습니다.

단순히 Search 라이브러리를 사용하는 것만으로도 쉽게 문제를 해결할 수 있었다고 합니다.

이처럼 단어의 명확한 의미를 파악하는 것으로 다른 라이브러리의 메서드를 활용할 때에도 큰 도움이 된다고 합니다.

 

 

2) 보다 구체적인 단어로 변경하기

 

https://www.youtube.com/watch?v=GD5TmEIEK38

 

김영하 작가는 "짜증난다"라는 표현을 사용하지 않기를 권장합니다. 짜증이라는 감정은 다양한 감정이 뭉뚱그려진, 추상적인 감정이라 정확한 감정을 파악하기 어렵습니다.

 

예를 들어, 서운한 경우도 짜증이 날 수 있고, 억울한 경우에도 짜증이 날 수 있습니다. 즉 모호한 표현을 글쓰기에 반영하면 화자의 정확한 감정이 전달되지 않는다는 것이죠.

 

coze님은 코드 작성은 글쓰기와 유사하다고 합니다. 그래서 코드 작성을 할 때에도 추상적이고 광범위한 의미를 내포한 단어 보다 구체적인 단어로 변경하는 것이 좋다고 합니다.

 

예시를 한 번 살펴보도록 하겠습니다!

 

if(expirationTime < PROMOTION_END_TIME){
	return remainTime / totalTime;
}

위의 코드는 이해하는데 큰 무리가 없습니다. 만료 시간을 비교한 조건을 통과하면, 남은 시간을 전체 시간으로 나누는 것을 이해할 수 있죠.

하지만, Time은 모호한 단어입니다. Time은 어떤 형식으로 작성된 것인지 알지 못합니다. 시간-분-초로 이뤄진 시간인지, 날짜까지 포함된 형식인지, 년~초의 단위를 모두 변환해 초로 나타낸 값인지 알지 못합니다.

 

if(expirationDate < PROMOTION_END_DATE){
	return remainDuration / totalDurtion;
}

다음은 변경된 코드입니다. 정확한 Date로 'Date'형식의 값을 얻어오겠다! 라는 의미를 부여하고,

나눌 수 있는 것은 시각이 아닌 '양'을 뜻하는 시간의 차이므로 Duration을 사용해 의미를 부여한 방식으로 가독성을 개선했다고 합니다.

확실히 이전보다는 와닿는 게 있었습니다.

 

이 외에도 모호한 단어를 구체적으로 표현할 수 있는 예시는 아래와 같다고 합니다.

대체 단어
get(가져오다)	extract(추출하다) / parse(분해하다) / aggregate (합치다)
number(숫자)	limit(제한이 있는 수) / count(총계)
change(변경하다)	convert(변환하다), filter(거르다), override(덮어쓰다)
changed(바뀐)	dirty(더러운 = 수정이 이루어진)

 

예를 들어, extract를 사용하면, parameter로 들어온 값 중에 일부 필드만 추출해서 반환한다는 것을 알 수 있습니다.

일반적으로 get를 사용한 경우보다 훨씬 이해하기 편할 것입니다.

 

 

3) 항상 정확해야 하는가?

 

정확한 단어로 명세하는 것은 분명히 가독성에 큰 도움을 주었지만, 때로는 항상 정확할 필요는 없다고 합니다.

위의 코드를 보면, 앞으로 분/시/일을 초단위로 변경할 예정이기 때문에, 정확한 표현으로는 MIN_TO_SEC, HOUR_TO_SEC, DAY_TO_SEC로 표현하는 것이 올바릅니다.

 

하지만, 코드를 살펴보면, 아래의 경우가 전체적인 맥락이 더욱 더 잘 읽히는 경향이 있습니다. 분명 정확한 표현은 위의 코드지만요.

따라서 항상 정확한 표현을 찾기 보다는 문맥을 파악해 가독성 확보을 확보하려는 노력이 필요하다고 합니다.

 

 

 

1-2. 잘보이는 형태로 작성하기

글쓰기를 할 때 한 눈에 잘 들어오게 작성하려면 보통 어떤 것들을 사용할까요?

단순히 글로 표현하는 것보다, 표를 사용하거나 용어 정리, 목차, 그림, 차트 등을 사용해 시각적으로 나타내어 눈에 더욱 더 잘 보이게 표현합니다.

 

coze님은 이러한 부분을 코드 작성에서도 연계하여 가독성을 높이려는 노력을 했습니다.

 

 

1. 표

const type = 
	exception
    ? undefined
    : condA
    ? 'A'
    : condB
    ? condC
    	? 'BC'
        : 'BD'
    : 'A';

위의 코드는 지독한 삼항 연산자의 향연입니다. 로직은 잘 실행될 지 모르지만, 직관적으로 눈에 이 코드가 들어오지 않았다고 합니다.

조건에 따라 값이 결정되는 로직을 표로 나타내면 어떨까요?

다음과 같이 한 눈에 어떤 조건에 의해 값이 결정되는 지 알 수 있습니다.

이를 코드로 최대한 표와 비슷하게 나타낸 것이 아래의 예시라고 합니다.

let type = 'A';
if (exception) type = undefined;
if (condA) type = 'A';
if (condB) {
	if (condC) type = 'BC';
    else type = 'BD';
}

 

확실히 전 보다 명확하게 구조를 파악할 수 있었습니다. 비록 if 문이 늘어난다고 하더라도, 복잡한 삼항연산자를 연이어 사용하기 보다는 이런 것이 개발자가 이해하기에 훨씬 편한 코드임을 알 수 있었습니다. 

 

 

2. 목차

 

UI 컴포넌트의 앞 뒤 위치의 갚을 나타내는 zIndex와 관련되어 나온 키워드로, 프론트엔드에 대한 지식이 부족하지만 요약하자면,

프론트엔드 UI의 모든 컴포넌트의 zIndex 값을 관리하는 '목차'를 생성해 해당 값을 가져오는 방식으로 코드를 변경했습니다.

백엔드에서도 목차로 나타내는 것은, enum 혹은 스태틱 변수를 통해서 충분히 구현할 수 있는 방법이니 필요시 적극적으로 기용하려는 노력을 해야 할 것 같습니다.

 

 

 

3. 용어정리

700

 

용어 정리와 같은 경우는, 이해하기 어려운 파트를 독자가 읽을 때 도움이 될 수 있도록, 따로 설명한 부분을 의미합니다.

아래의 코드가 용어 정리를 코드에 적용한 경우라고 합니다. 코드가 조금 더 길어졌다고 하더라도 연산에 대한 부가 설명을 중간의 변수를 통해 넣을 수 있으므로 확실히 디테일한 코드라고 볼 수 있습니다.

 

개인적인 생각이지만, 위와 같은 코딩 방식에 익숙해져서 그런지 아래의 코드가 눈에 잘 들어오는 느낌은 아녔습니다.

물론 읽다보면, 어떤 의미인지 잘 들여다 볼 수는 있겠지만요.

적절한 사용을 통해 가독성을 늘리는 것은 제 몫이라고 생각합니다.

 

https://speakerdeck.com/kakao/seomsehan-isfpyi-kodeu-gadogseong-gaeseon-gyeongheom

 

 

 

😮 2. 후기

 

코드 작성의 퀄리티는 정해진 정확한 이론이 있는 것이 아니라, 개발자의 경험에 많이 달려있습니다.

이런 세심한 배려가 돋보이는 개발자의 생각을 공유 받을 수 있어서 좋았습니다.

 

가장 깊은 감명을 받은 부분은, "정확한 단어" 파트였습니다. 아무런 생각 없이 단순하게 사용했던 단어들이 그런 뜻을 내포하고 있었는지 몰랐다는 점에서 조금 부끄럽네요.

 

비록 프론트엔드 코드가 많이 나와 이해가 부족한 부분도 있었으나 "아, 내 코드에서도 충분히 적용할 만한 부분이 많다!"라고 느낀 부분도 많기 때문에 굉장히 유익한 컨퍼런스였습니다.

 

 

 

🏝 출처

[슬라이드] https://speakerdeck.com/kakao/seomsehan-isfpyi-kodeu-gadogseong-gaeseon-gyeongheom
[컨퍼런스] https://www.youtube.com/watch?v=emGLxi0LvNI&list=LL&index=46&t=165s