> 개요
프로젝트를 진행하다 보니, 정해진 기한에 맞춰 결과만 생각하다 보니, 로직이 잘 돌아가는거에만 급급했다. 프로젝트 종료 후 다시 내 코드를 보니 굉장히 엉망진창이라고 느끼게 되었다.
다시 코드를 정독하면서 느낀점은, 함수명이 정확하지 않아, 어떤 기능을 하는 함수 인지 구분하기 힘들었고, 컴포넌트가 명확히 분리되어 있지 않다보니, 리액트의 최고의 장점중 하나인 컴포넌트화가 제대로 되어 있지 않다는 것을 발견할 수 있었다.
그러다보니, 한 컴포넌트에 코드량이 많다거나, 가독성이 좋지않다는 단점을 발견할 수 있었다.
그래서, 이번기회에 그런 부분들을 리팩토링 해보며, 반성할 수 있는 기회를 마련해 보았다.
> 그래서 리팩토링이 먼데??
💡 리팩토링? 이란 소프트웨어 공학에서 '결과의 변경 없이 코드의 구조를 재조정함' 이라고 위키백과에 설명되어 있다.
1️⃣ 첫번째로 컴포넌트 분리
프로젝트 당시는 진짜 정신이 없었나 보다 라고 생각하게 된 계기는 다시 코드를 차근차근 정독하며, 내가 했던 파트들을 보면서 느낄 수 있었다.
왜냐하면 코드가 너무 정신이 없었다. 그래서 정작 내가 작선한 코드이지만 알아볼 수가 없었달까...
사진에서 보이겠지만, 컴포넌트를 제대로 분류하지 않아서 무려 140줄이나 되는 코드가 한 컴포넌트에 있는 상황이었다.
보면서 나도 어디가 어딘지 모르겠는데, 만약 같이 일하는 팀원이 이걸 본다고 생각하면, 속으로 욕해도 할말이 없었다. 그래서 첫번째로 컴포넌트를 나누기 시작했다. 최대한 나눌수 있는건 나누었고, 나누면서 필요한 state는 따로 만들거나, props 로 넘겨 주면서 에러들을 처리할 수 있었다.
결과적으로, 나는 140줄의 코드에서 50줄로 무려 90줄 의 코드를 줄일 수 있었고. 컴포넌트로 기능별로 나누워 가독성이 좋게 하였다.
2️⃣ 함수명 변경
기존 코드에서는 함수명을 정할 때, 공통적이기 보다는 그냥 그때 생각 나는 대로 선언했다.
예를 들어, 가격별로 정렬을 해주는 함수가 있다고 하면 sortIncrese, sortDecrease 이런식으로 내가 보기에는 좀 알아듣기 쉬울거라고 생각했지만, 또 찾아보니 현업에서는 다르게 쓴다는 글을 보았다.
그래서 결과적으로 productSortAsc, productSortDesc 보기에는 그 전 선언명과 별반 다를게 없지만, 그래도 실제 현업에서 많이 쓰는 방법으로 익혀둬야, 서로서로 읽기도 편하고 배려해주는게 같다.
3️⃣ 스타일 변경 및 파일명 변경
- 스타일 변경
기존 페이지에 별로 중요하지 않다고 생각하지만, 나는 이런 디테일한 부분이 사용자를 조금이라도 배려하기 위한 방법이라고 느꼈다.
기존에는 그냥 회원가입 이라고만 표시가 되어있었다. 나도 초반에는 다른 생각없이 지나갔는데, 다른 페이지들도 살펴보며 비교를 해보니 진짜 별거 아니지만, 예의없어 보인달까... 그랬다 어쨋든 그래서 그냥 회원이 아니시면 회원가입해달라는 유도질문? 같은걸 넣어보았다.
- 파일명 변경
파일명 같은 경우도 통일성을 주는게 좋다고 생각했다.
왜냐하면, 페이지가 많아지다 보면, 한페이지만 해도 컴포넌트를 나누다 보면 한페이지 폴더안에 2~3개의 폴더가 더 들어가게 되는 경험을 한 적이 많다.
그래서 여기저거 페이지를 열다보니 여기가 지금 어느 페이지인지 헷갈리고, 파일이 이것 저것 많이 열러놓다보니, 잘못하면 실수도 다른 페이지에서 작업을 할 경우도 생길 수 있을거 가능성이 있어서 이것도 수정을 해주었다.
수정하고 보니 굉장히 깔끔했고, 가독성이 한층 올라가는 결과를 맛보았다.
현재도 계속 진행 중인 작업이다. 이번 기회에 리팩토링의 중요성을 절실히 느끼는 작업이었다. 비록 끝난 프로젝트이지만, 다시 돌아감으로 인해서, 그 당시 좋치고 지나갔던 부분을 새로이 학습 하는 경험이었고, 이런 경험들이 다음 프로젝트를 할 때, 더 집중할 수 있도록 하는 좋은 작업이었다.
추후에는 Redux도 적용할 것이고, 거기다 Typescript로도 변환을 생각하고 있다.
취뽀하자!!!
