원할한 협업을 위한 노력 (1) 코드 리팩토링

1. 요구사항

사이드 프로젝트로 진행했던 사라 마라 웹사이트를 조금 더 고도화하기로 결정했고, 그에 따라 기존에는 나 혼자 하던 프런트엔드 개발을 한 명 더 추가해서 진행하기로 했다. 이 과정에서 기존에 작업된 내용물을 새로운 팀원과 설명해주어야 했고, 함께 작성하기 위한 몇 가지 규칙을 정하기로 하였다.

---

1. 리펙토링을 하자

1-1. 요구사항

새로운 개발자님이랑 처음으로 코드를 설명해 주기 위해 줌 미팅을 했지만, 생각보다 내 코드를 설명해 주는 것이 쉽지 않았다. 그 이유는, 첫 번째로 주석 처리가 부족하다. TDD를 염두에 두며 아주 작은 view 단위도 컴포넌트화 했지만, 주석이 부족했기 때문에 새로운 개발자가 재사용은커녕 코드를 이해하기도 어려웠다. 두 번째로, 폴더구조가 복잡하였다. 각각의 모듈을 component - page - layout와 같은 용도별로 디렉터리에 보관하였다. 이런 구조는 하나의 폴더 안에 너무 많은 파일이 들어가게 되기 때문에 프로젝트 규모가 조금만 커지더라도 원하는 파일을 찾는데 많은 시간이 소요되었다. 사실 3일간의 시간 동안 웹 프런트페이지를 급하게 만드느라 이러한 내용을 깊게 고민하지 못하였는데, 혼자 작업하려다가 같이 작업하게 되니 이러한 문제가 더 크게 나타났다.

1-2. 변수명 컨벤션을 지키고 공용컴포넌트는 꼭 주석을 작성하자

이러한 문제를 해결하기 위해 첫번째로 했던 작업이다. naming-convention에 관해 정리된 사이트를 참고하여 네이밍 컨벤션을 작성하기로 했고, 특히 동사 + 명사조합을 사용하기로 하며 이와 맞지 않는 변수명을 수정하였다.

그리고, 함수의 재사용성과 서로의 코드를 알아보기 위해 /** */ 코드를 사용하였다. 선언전에 이 코드를 작성한다면 선언한 함수를 사용할 때 해당 함수에 대한 간단한 설명과 params, return 정보를 알 수 게 되기 때문에 원활한 협업에 도움을 줄 것이라 생각하였다.

/* **/ 주석 사용 모습

1-3. 폴더 구조를 개선해보자

또 한 가지의 문제는 폴더구조가 너무 복잡하다. 아니 너무 간단하다. 특성별로 (layout - components - page)로 나눈 모듈들의 코드를 찾기 위해서는 하나의 폴더에서 많은 파일 속에서 내가 원하는 파일을 찾기에는 너무 힘들었다. 사실 자칭 라이브러리인 React는 폴더구조에 대한 명확한 기준을 두지 않기 때문에 폴더 구조를 어떻게 개선해야 할지 새로운 개발자님과 함께 고민했다. 그 와중에 잘 정리된 리액트 폴더구조에 관한 글을 찾았고, 이 글에서 말하는 기능별 파일구조를 프로젝트에 도입하기로 하였다. 간단하게 정리하면 모든 기능(라우터)에서 공용으로 사용하는 컴포넌트 훅 등을 제외하고는 나머지는 features라는 폴더구조 안에 각각의 기능별로 정리하는 방법이다.
예를 들면 auth, commerce라는 기능을 가진 프로젝트에서 auth에서 사용하는 api는 features / auth / api / getLoginState.js 이렇게 보관하고, commerce에서 사용하는 api는 features / auth / api / getItemList.js 에 보관하는 방식이다.
위 사이트에서 사용한 방법을 우리 프로젝트에 맞추어 아래와 같이 정리하였다.

 src
|
+-- assets            # 전체 프로젝트에서 사용해야할 이미지 (로고, 테스트 등)
|
+-- components        # 컴포넌트
|
+-- config            # all the global configuration, env variables etc. get exported from here and used in the app
|
+-- features          # 각각의 기능 / 도메인 별로 분리
|
+-- hooks             # shared hooks used across the entire application
|
+-- lib               # 라이브러리 수정 및 관리
|
+-- providers         # all of the application pr
|
+-- routes            # routes configuration
|
+-- stores            # global state stores
|
+-- test              # test utilities and mock server

 src/features/SomeComponent
|
+-- api         # exported API request declarations and api hooks related to a specific feature
|
+-- assets      # assets folder can contain all the static files for a specific feature
|
+-- components  # components scoped to a specific feature
|
+-- layouts     # components 를 가지는 집합 components에 사용될 state는 layout에서 props로 전달
|
+-- hooks       # hooks scoped to a specific feature
|
+-- routes      # route components for a specific feature pages
|
+-- stores      # state stores for a specific feature
|
+-- types       # typescript types for TS specific feature domain
|
+-- utils       # utility functions for a specific feature
|
+-- index.ts    # entry point for the feature, it should serve as the public API of the given feature and exports everything that should be used outside the feature

1-4. 마무리

우선 위 노력을 통해 협업을 하기 위해 코드를 개선하였다. 다행인 부분은 아직 프로젝트 규모가 크진 않았기 때문에 비교적 쉽게 코드를 수정할 수 있었고, 바뀐 코드를 바탕으로 새로운 개발자님에게 코드를 성공적으로 설명해 줄 수 있었다. 리팩토링을 통해 과거를 수정하며 협업을 위해 노력했다면, 이제 함께 할 작업을 위해 미래를 대비할 차례였다. 이 프로젝트를 진행하며 하며 나와 새로 온 개발자님 모두 코드리뷰를 하면 좋겠다는 목표가 있었고, 꾸준한 기능 개발과 개선작업을 염두에 두고 있었기 때문에 어느 정도 협업 환경을 구성하면 좋겠다고 생각하여 노력하였다.

문서 길이가 길어져 협업환경을 위해 노력한 부분은 다음글에 추가로 정리하겠다.

ps. 사이드 프로젝트에서 꾸준히 개선해나가고 있는 사이트입니다. 한 번씩 사용해 보시고 피드백 부탁드립니다 :)
http://sara-mara.com/