리팩토링 스터디 #6 - 리팩토링 준비하기

오랜만의 리팩토링 스터디 포스팅입니다. 이번 회차에서는 실제 리팩토링을 준비하는 과정을 주제로 작성해보려고 합니다. 6주차 스터디에서 나온 내용만으로 한 포스팅을 채우기 살짝 부족한 느낌이 있어 7주차의 특정 부분을 덧붙여 함께 작성하였는데, 마침 이 내용이 적절해보였습니다.

 

스터디 구성원들과 이야기를 하던 중 지금까지 리팩토링을 어느정도 공부했으니, 실제로 리팩토링을 한 번 해보면서 공부한 내용들을 복습해보는것이 어떨까에 대한 이야기가 나왔습니다. 좋은 기회라는 생각이 들어 4주차쯤부터 적절한 라이브러리를 찾기 시작했습니다. 적절한 라이브러리의 조건으로는 어느정도 유지가 되어 구조적인 결함이 생겼을 확률이 높고, 실제 사용자가 많아 오픈소스 컨트리뷰팅을 하기 좋은 라이브러리 정도로 목표를 잡았습니다. 덧붙여서 이 책에선 자바스크립트를 기반으로 설명했으니, 기왕이면 자바스크립트로 된 라이브러리였으면 더욱 좋겠지요.

 

 

리팩토링 기법을 실습할 라이브러리를 찾아서

 

처음엔 스터디 구성원들의 프로젝트를 리팩토링 해볼까? 라는 의견이 나와 한 명 한 명의 퍼블릭 레포지토리들을 탈탈 털어보았는데, 적당한 대상이 없어 다시 오픈소스 쪽으로 발길을 돌리게 되었습니다. (스파게티처럼 엉킨 제 코드를 구성원들 앞에서 분석하는 불상사가 일어나지 않아 정말 다행이었습니다) 매 주 스터디를 준비하며 여러 라이브러리를 찾아보며 의논하였고, 최종적으로 결정하게 된 라이브러리는 바로 Axios입니다.

 

npm axios

 

axios는 HTTP 클라이언트에서 비동기 통신을 도와주는 대표적인 자바스크립트 라이브러리입니다. 보통 자바스크립트에서 통신을 한다고 하면 이 AJAX와 더불어 가장 많이 보이는 라이브러리입니다. 주간 다운로드를 보시면 천만 단위의 숫자가 찍혀있는 것을 볼 수 있습니다. (2020년 12월 첫째 주 기준)

 

가벼운, Promise 기반의, XHR 라이브러리를 지향점으로 2014년에 시작된 이 프로젝트는 2020년 현재 1000개에 가까운 커밋 로그를 남기고 250명이 넘는 컨트리뷰터가 함께할만큼 수 많은 사람들이 사용하고 기여한 대중적인 라이브러리가 되었습니다. 저도 네트워크 통신 기능을 구현하며 몇 번 사용해 본 기억이 있네요.

 

#axios, 첫 커밋

 

하지만 그만큼 내용이 방대하다보니 쉽사리 손을 대기가 정말 어려웠습니다. 코끼리를 더듬는 장님의 심정이 이랬을까요. 더군다나 저보다 개발 경험도 훨씬 많고, 실력있는 여러 개발자분들이 모여 만드신 라이브러리인만큼 내부 구조를 짜더라도 제가 생각했던 부분은 물론 그 이상도 이미 다 알고 계셨을테니 코드를 보면서도 "이게 맞는 코드겠지.", "이렇게 짠 이유가 있겠지." 하는 마음이 먼저 들기도 했습니다.

 

다행히 이번 리팩토링 스터디는 든든한 선배님들과 함께하는 스터디인터라... 능숙하게 코드들을 짚어보시는 모습을 옆에서 같이보며 조금씩 구조를 익혀나가게 되었네요. 코드를 보며 나왔던 이야기들을 몇 가지를 정리해보았습니다.

 

 

디렉토리를 나누는 기준

코드를 작성하다보면 기능에 따라 많은 함수들을 작성하게 됩니다. 그 중 비슷한 작업을 하는 함수들끼리는 한 파일에 모아놓으면 프로그래머의 입장에서 코드를 관리하기 수월해집니다.

 

Axios에서도 이러한 특성을 생각하며 폴더를 살펴보았습니다.

 

Axios/lib

 

 

주요 코드들이 들어있는 lib 폴더입니다. core 폴더는 말 그대로 Axios의 핵심적인 부분들이 들어있습니다.

 

언제나 옳은 README.md

요청 발송(Dispatching request), 인터셉터 관리(Managing interceptors), 구성 제어(Handling config) 등의 기능을 하는 모듈이 여기에 있습니다. 간단히 말해서 특정한 도메인에서 이루어지는 동작들을 모아놓은 모듈들인데, 이런 모듈들은 너무 지엽적이고 구체적이기 때문에 core 안쪽에 보관하고 하나의 카테고리로 묶어 사용하는 것이 좋아 보입니다.

 

 

'not' specific to the domain logic of axios.

 

helpers 폴더에 있는 파일들은 특정한 도메인에서 이루어지지 않은 동작들을 보조하는 역할을 합니다. core에 있던 코드들이 처리하지 못하는 넓은 범위에서 사용되는 코드들인데, 말 그대로 helper 라는 이름이 어울리는 역할이네요. 이론적으론 npm에 올려서 다른 모듈이나 프로그램에서도 사용될 수 있는 그런 함수들을 모아놓은 장소라고 보시면 될 것 같습니다.

다음은 utils.js 입니다. utils 같은 경우 따로 폴더로 나누어지지 않고, 파일 하나로 묶여있는데 이 코드들은 개별 파일로 분리할 필요가 없는 간단한 코드들로 구성되어 있습니다.

 

가장 긴 함수도 사실상 주석을 제외하면 20줄 남짓입니다.

 

실제로 그 중 가장 긴 함수를 찾아보려고 스크롤을 내려보니 forEach()가 나왔는데, 그 마저도 주석을 제외하면 정확히 21줄이었습니다. 함수 내용도 매우 직관적이고 간단합니다. 배열 뿐 아니라 순서 있는 오브젝트같은 이터레이터들까지 순회할 수 있도록 제작된 함수입니다.

 

따라서 utils는 순수한 함수들(의존적이지 않은)이고, 사용했을때 사이드 이펙트가 없는 함수들의 모임입니다. helpers의 함수들도 비슷한 부분이 있죠.

 

그럼 어떠한 코드들을 작성한다고 했을때, 이 코드들을 utils에 넣어야 할지, helpers에 넣어야 할지. 이런건 어떻게 정하는 것이 좋을까요? 정답은 바로 코드리뷰입니다.

 

코드리뷰를 통해 이 함수가 있어야 할 적절한 위치를 정하고, 엉뚱한 곳에 있다면 바로 잡아주는 과정을 거쳐 비로소 짜임새 있는 함수로 태어나게 됩니다. 직접적으로 코드를 짜는 시간(타이핑)보다 이러한 리뷰와 수정에 들어가는 시간이 많은 이유도 같은 맥락에서 나옵니다. 그래서 더더욱 코드를 읽는 방법이 중요한걸지도 모르겠네요.

 

오픈소스의 경우, 많은 재야의 고수분들이 집단 지성을 모은 결과물이므로 코드를 읽는 연습하기에 정말 좋은 것 같습니다. 아는만큼 보인다는 말처럼, 코드도 읽은만큼 보인다는 말이 맞는 것 같아요.

 

당분간은 꾸준히 axios 코드와 이슈를 확인하며, 리팩토링할만한 내용이나 기여할 내용을 찾아보며 지내봐야겠습니다. 이미 많은 분들이 거쳐간 코드라 쉽지는 않겠지만 잘 찾아보다보면 하나쯤은 있지 않을까요 :)

다음 리팩토링 글에서 뵙겠습니다.