본문 바로가기

개발/Front-end

[React] 가상화폐 자동거래 프로젝트 리팩토링하기(2/2)

이번 포스팅은 지난 가상화폐 자동거래 프로젝트 리팩토링하기 두 번째 편이다.

사실 오래 전에 작업했던 내용인데 갑자기 반응형 웹을 공부한다고 그 포스팅을 하다 보니 조금 미뤄졌다. 지난 리팩토링 때는 컴포넌트 모듈화 방식의 변경을 통하여 한 줄로 간단히 사용되는 컴포넌트들을 정리했었다. 이번에는 변수 및 함수 이름을 수정하는 작업을 진행해보았다.

 

굳이 내가 사용한 변수명 또는 함수명이 명확할 필요가 없고 중요하지 않은 않은 알고리즘 문제 풀이와 같은 코드에서는 `a, b, c, tmp` 등등 크게 의미가 있는 이름은 사용하지 않는다. 하지만 유의미한 변수명은 프로젝트를 진행할 때는 중요해진다. 왜냐하면 변수명을 잘 짓는 것만으로도 코드를 보게 될 사람들에게 많은 정보를 줄 수 있기 때문이다.

"읽기 좋은 코드가 좋은 코드다" [1]에서는 변수명을 개선할 수 있는 6가지 방법을 제안하였다.

  1. 특정한 단어를 사용하라.
  2. 이유가 없다면 tmp 등과 같은 보편적인 이름의 사용을 피하라.
  3. 대상을 자세히 묘사하는 구체적인 이름을 덧붙여라.
  4. 세부 정보를 덧붙여라.
  5. 사용 범위가 넓으면 긴 이름을 사용하라.
  6. 대문자나 밑줄 등을 의미 있는 방식으로 활용하라.

이 중 적용할 수 있는 몇 가지 요소들을 반영해 리팩토링을 진행하였다.

 

리팩토링 작업 내용

보편적 이름의 사용 피하기 & 대상을 묘사하는 구체적인 이름 덧붙이기

기존 코드에서는 자동 거래 기록을 담는 state 변수를 단순히 logs로 두었다. 이 logs라는 이름은 보편적으로 기록과 관련된 변수에 사용되기 때문에 광범위하게 해석될 요지가 있다. 어떤 기록인지를 명확하게 작성하기 위해 구체적인 이름인 tradingRecords로 이름을 변경하였다. 이에 맞추어 하위 컴포넌트의 props에 해당하는 내용들도 모두 변경해주었다.

 

이전 logs의 경우 보았을 때, 어떤 기록을 담음을 알 수는 있지만 해당 기록이 어떤 기록인지 확인하기 위해서는 코드를 살펴봐야 할 필요가 있다. 이 프로젝트에서는 자동 거래 기록을 렌더링 하는 컴포넌트를 확인하고 나서야 이 변수가 자동 거래 기록을 의미함을 알 수 있다. 이를 거래 기록을 영어로 변경한 trading records로 바꿈으로써 변수 이름만 보고도 이 변수가 거래 기록과 관련된 내용이 담겨 있음을 이전에 비해 쉽게 유추할 수 있다. 추가적으로 변수명을 단수형이 아닌 복수형을 사용함으로써 복수의 데이터를 갖고 있는 자료형임 또한 유추할 수 있다.(사실 이는, useState의 타입과 디폴트 값 지정을 통해 수행해야 하지만 아직 이를 개선하지는 않았다.)

세부 정보 덧붙이기

작업의 3번에 해당하는 내용이다. 기존에는 GNB 영역에 해당하지 않는 페이지의 콘텐츠들이 포함되는 태그라는 의미로 className에 contents를 배정했지만 이를 applicationMain, 즉 우리의 어플리케이션의 주된 내용들이 렌더링 될 태그라는 의미를 부여하였다. 어찌 보면 보편적인 이름이라고 볼 수 있지만, 때로는 보편적인 이름이 가장 좋을 때도 있다고 생각해서 이와 같이 리팩토링을 진행하였다.

정리

오늘은 책[1]에서 본 내용을 토대로 코드를 이루고 있는 변수와 함수의 이름을 리팩토링해보았다. 우스갯소리로 개발자들이 하루 일 하는 시간 중의 대다수는 변수와 함수의 이름을 고민하는 데 사용한다는 얘기를 들은 적이 있다. 좋은 이름을 붙이는 연습이 아직 부족한 지금의 상태에서는 기능 구현에 조금 더 집중이 되기 때문에 이 부분을 놓치기 쉽다. 개인적으로 프로젝트 경험 시 내가 붙인 이름이 기억이 나지 않아서 다시 찾아봐야 하는 등의 경험 또한 존재한다.

작은 부분이지만 연습을 통해 디테일한 부분을 보강하면 보다 더 좋은 코드를 작성할 수 있는 개발자가 될 수 있을 것 같다는 것을 직접 해보며 느낄 수 있었다. 그리고 앞으로는 조금 더 신경을 써야겠고, 영어 공부를 해야겠다는 생각 또한 하게 됐다.

 

일단 현재 진행할 수 있는 리팩토링은 이 정도로 마무리를 하고, 프로젝트에서 청산하지 못한 기술적 부채들을 하나씩 해결해나가며 다시 리팩토링을 진행하게 되지 않을까 싶다. 리팩토링이라는 거창한 이름을 가진 크지 않은 행동이었지만 그래도 진행하며 많이 직접 경험하며 느낄 수 있는 시간이 됬던 것 같아 개인적으로 뿌듯하다. 앞으로 다음 리팩토링 때는 보다 더 정돈된 형태로 돌아올 수 있으면 좋겠다.

출처

[1] 더스틴 보즈웰, 트레버 파우커. "읽기 좋은 코드가 좋은 코드다".  O'REILLY, 한빛미디어(2018). p30-p48

반응형