프론트엔드 프로젝트를 진행하고 문의 대응을 하면서 내 코드도 몇달 뒤에 보면 다른 사람 코드 처럼 느껴졌다.
내가 짠 코드지만, 나도 파악 할 시간이 필요해.
아무리 내가 짠 코드지만 다시 코드를 파악하는 시간이 어쩔 수 없이 들어가게 된다. 그렇다면 파악해야하는 코드의 양을 줄이고 조금 더 본인 또는 타인이 봤을 때 이해하기 쉬운 코드를 짜는게 효율적이지 않은가?
그리고 더불어 웹사이트의 성능까지 최적화, 무리를 줄이는 리펙토링까지 하면 점점 더 완벽한 코드를 만들 수 있을 것이다.
그렇다면 필자가 프로젝트에서 어떤 경우에 어떻게 리펙토링을 했는지 알아보자.
코드가 너무 길고 복잡하다.
본인은 zustand를 쓰기전에는 useState로 모든 상태를 페이지에서 선언해주고 컴포넌트에 props로 하위로 넘겨줘서 컴포넌트에서 가공없이 사용할 수 있게 만들었다.
하지만, 페이지에 컴포넌트가 많고 비즈니스 로직이 점점 증가하면 코드가 엄청나게 늘어나고 가독성이 떨어져 코드 파악하기가 어려워졌다.
저렇게 코드를 짠 이유는 컴포넌트와 상태를 분리해서 항상 재활용이 가능한 상태를 유지하고 싶었다. 그런데 이것을 좀 집착처럼 유지하다 보니까 페이지에 코드들이 엄청나게 불어났다. 하지만, 어느정도 규모가 있는 컴포넌트는 재사용 될일이 없었다. 독립적이지만 재사용될 일이 없는 용량 큰 컴포넌트가 된 것이다.
보일러플레이트 최소화
props로 작은 단위의 컴포넌트까지 계속해서 하위로 보내주는 것에 피로감을 느끼고, 어느정도 컴포넌트가 독립적이고 사이즈가 커지면 따로 글로벌 상태로 관리하는게
복잡도를 줄일 수 있다고 생각했다. 그래서 본인은 zustand를 사용해서 페이지에서 상태 관리를 최소화하였다. 하지만, 원자성 컴포넌트들은 기존처럼 props를 받아 사용하게 유지를 했다.
유틸, 정적 data를 page에서 분리
유틸성 함수, 정적 data를 페이지에서 가지고 있을 필요가 없다. 본인은 현재 페이지에서만 한정해서 사용될 것 같은 유틸성 함수, 정적 data를 페이지에 선언 했었는데 페이지 용량만 커지고 더군다나 다른 페이지에서도 필요한 경우가 꼭 생긴다. 그냥 유틸 폴더에 따로 정리해서 사용하자.
초기 호출 api와 이벤트성 api의 분리
초기 화면에 출력되는 정보를 가져오는 api와 나중에 이벤트로 호출되는 api 를 분리해서 정리하였다. 초기 호출은 react query의 useQuery로 하였고 이벤트성은 useMutate를 사용하였다. 이건 라이브러리의 편리성이 좋아서 관리 체감이 좋아진 것도 있는데, api를 확실히 분리해서 사용하니까 api를 빠르게 파악하는데 도움이 되었다.
근데 리펙토링과 별개로 react query가 axios만을 사용할 때랑 비교를 하면 라이브러리가 압도적으로 관리가 편리하다.
결론
결국 성능적인 부분을 제외하면 가독성이 좋고 짧은 코드가 좋은 코드인 것 같다. 앞으로도 여러 방면을 생각해서 리펙토링을 할 수 있는 능력을 길러야겠다.
