refactoring

front-end refactoring 후기

기존 서비스를 재구성하여 여러 버전의 서비스를 생성하기 위한 전초작업으로, 기존 소스는 적은 인원으로 빠른 개발을 위해 정리가 되지 않은 소스가 많이 있습니다. 해당 소스 개발시기에 히스토리는 알지 못하고, 이후 정리과정에 투입되어 작업하게 되었습니다.

Legacy 프로젝트 구조

먼저 다음과 같은 stack을 사용중인 서비스 입니다.

• CRA(Create-React-app with typescript)
• tailwind
• websocket
• recoil (과도기)
• react-query (과도기)

몇몇 상태 및 기능등이 recoil에 올라간 경우도 있고 state-drilling을 통해 주입되는 경우도 있었으며, axios를 통해 localstate를 설정하여 사용하는 데이터와 react-query를 사용하는 경우가 혼재되어 있습니다.

개선 사항

routing의 통일

기존에는 page라고 하는 directory안에서 모든 component의 관리가 이루어지고 있었는데, 이 부분을 작게 나누어 unit-component와 page, routing으로 분리하여 구성합니다. page는 데이터 패치(API 호출 with react-query)및 recoil state handling을 하도록 하며, callback function등을 관리하여 결과 값을 처리하는 방식만을 구성합니다.

단일 컴포넌트 form, input등은 해당 컴포넌트에서 validate값을 조절하여 결과값의 T/F를 반환하여 처리기에 전달하는 역할만 구성합니다. 이러한 방식은 하나의 Input이 어떠한 역할을 하는지 이해하기 편리하지만, 전체 데이터의 validation체크를 어렵게하는 문제가 있습니다.

다만, 해당 서비스는 이후 비슷한 컴포넌트로 다양한 서비스에 다른 기능으로 추가할 계획을 가지고 있어 단일 컴포넌트의 custom이 더 쉬운 방식을 선택해 위와 같은 전략을 선택했습니다.

type 관리 통일성

현재 타입이 여러가지 디렉토리에 기준 없이 선언된 경우가 많아, 크게 두 가지로 나누어 분리하였습니다. common, api통신에 사용되는 type을 따로 모아서 관리하고, component props등의 단일 컴포넌트에 관련된 type을 묶어서 관리하는 방식을 선택했다.

common, api등은 entity의 성질을 띄는 type이 많고, component의 state, props등은 해당 컴포나 상호작용하는 하위 컴포넌트에 영향을 주는 경우가 많아 이렇게 구성했다.

api 호출 방식 통일

기존에는 component 레벨에 상관없이 routing 변경, api호출 등 데이터의 흐름을 파악하기 어려운 형태로 되어있었다. 위에서 언급된 routing 단계에서 데이터 흐름을 파악 할 수 있는 모든 기능을 선언하여 사용하고, 내부에 component에 핸들러를 주입하는 형태로 컴포넌트의 API, store관리 기능을 모두 한눈에 볼 수 있도록 배치했다.

기타 유틸 관리

json파일 등을 참조하거나, css파일을 직접 참조하는 경우가 더러 있었기 때문에, 해당 파일을 한군데서 관리 할 수 있도록 하였다.
const형태의 값을 사용되는 그때 그때 선언하여 사용해, 같은 이름의 const 값들이 다른게 설정되는 경우 발생하고 있었다. 이러한 경우를 방지하고 통일된 const, regex를 사용하기 위해 한군데서 관리하도록 정리했다.

트러블 슈팅

개발 일정 유지 및 리팩토링

기존 개발 일정을 가지고 리팩토링을 병렬로 진행해야하는 상황이었다. 테스트 코드가 없이 동시에 작업을 진행하니 conflict 발생도 빈번하게 일어나고, 갑자기 기능 상의 문제가 생기면 문제 사항을 찾아다니는데 큰 어려움이 있었다.
최대한 같은 부분의 작업을 하지 않도록 테스크를 순차적으로 나누었으나, 워낙 많이 꼬여있던 터라 분류해서 작업하는게 어려운 상황이었다.

tsc를 통해 push전에 잡을 수 있는 버그를 수정하고, conflict 이후에는 간단한 e2e 테스트를 진행해서 실제 서비스에서 큰 문제가 발생하는지 체크하는 방식을 선택했다.

당장 자세한 테스트 코드를 명세하는것은 어려워, e2e에서도 routing error 잡는 정도의 기능만 확인했다. 이후 구조 변경이 모두 끝나면 한번에 bugfix를 하는 방식을 선택했다.

response mapping

api명세가 명확하지 않은 상황에서 axios로 호출하던 api를 react-query에 옮기다가 정확한 데이터가 입력되지 않는경우가 있었다. 기존 response를 any로 사용하는 경우가 많아. 정확하게 잡히지 않는 타입이 문제가 되었다. 최대한 비슷한 구조로 맞춘다고 하였으나, data라고 하는 key가 너무 많이 중첩되어 발생하는 경우가 있었다.

api response를 fetching하려 한다면, 사전에 어떤 형식의 response를 사용할 예정인지 정하고 들어가거나, api document라도 작업을 같이 하면서 진행해야겠다.