[수풀] 메인 프로젝트 리팩토링을 하며 느낀점

1. 처음부터 코드를 잘 짜야한다.

리팩토링을 하면서 뼈저리게 느낀 것은 처음 짠 코드가 굉장히 중요하다는 것이었다.

처음에 제대로 짜인 코드가 유지 보수 측면에서 굉장히 이점이 있다는 걸 깨달았다.

처음 메인 프로젝트를 진행할 때, 전역으로 관리하는 상태에 대한 필요성에 대해 정확히 알지 못했다.

지금도 정확히 안다고는 표현할 수 없지만, 이번에 리팩토링을 하면서 전역 상태가 왜 필요한지 몸으로 느낀 것 같다.

 

메인 프로젝트 때에는 그냥 한 컴포넌트에 여러 기능들을 넣어 props로 내리면 되겠지라고 생각을 했다.

따라서 자식 컴포넌트에 props를 전달하고, 또 그 자식 컴포넌트에 props로 연결하여 완성했다.

3개의 컴포넌트로 하나의 페이지를 이루어 사용했지만 그 안에 너무 많은 코드량과 너무 많은 로직들이 있었고,

결국 이 컴포넌트들은 서로 얽히고 설켜서 컴포넌트 분리에 실패했다.

 

여기서 전역 상태의 필요성을 느꼈다. 물론 메인 프로젝트에서 만든 것처럼 자식의 자식의 자식... 이런 식으로 만들면 되겠지만

기능별로 컴포넌트를 나누지 못하고, 나눈다고 해도 수많은 props drilling을 일으키기 때문에 전역 상태가 필요하다고 판단했다.

하지만 막상 이미 만들어진 코드를 두고 전역상태로 관리하려고 하니 너무 막막했다.

여기서 아... 코드는 처음부터 이쁘게, 기능별로 짜야하고 처음에 계획할 때 정말 잘 계획해야 하는구나라고 생각하게 되었다.

내가 판단하기에는 처음부터 다시 코드를 짜야할 것 같은 느낌이 들고, 코드를 다시 짜야하는 건 또 리팩토링이 언제까지 이어질지 모르기에 이 작업은 천천히 리덕스를 다시 공부하면서 여유시간에 해야 될 것 같다.

 

2. TypeScript는 필수인 것 같다.

메인 프로젝트는 Js로 작성했었는데 1.5달 뒤에 다시 돌아오니 뭐야 이거 어떻게 돌아가는거지? 매개변수는 뭘 넣은 거고...

이렇게 다시 프로젝트를 파악하는데 시간이 좀 필요했던 것 같다. 하물며 내가 작성한 코드인데도 이렇게 버벅거리는데 나중에 다른 사람 코드를 직접 수정해야 할 때, 더욱 오랜 시간이 걸릴 거 같다. 

 

또한  아직 그렇게 TypeScript에 완벽히 적응한 게 아니어서, 리팩토링을 하면서 로직을 수정할 때 먼저 JavaScript로 수정을 한 뒤 TypeScript로 바꿔주려고 했는데 에러가 어디서 발생하는 건지 알기도 어렵고 실행이 되는 것처럼 굴다가 나중에 뒤통수를 쳐버리니 그냥 처음부터 TypeScript로 시작했다. 

 

여기서 느낀 것은 처음에 짜인 코드가 명확해야 유지 보수에 유리하다는 것. (매개변수에 타입을 지정해줌으로써 이 함수에 무엇이 들어가는지, 이 함수가 무엇을 행하는 함수인지 한눈에 파악하기 쉽다.)

나중에는 TypeScript를 쓸 때 구글링을 안 해도 척척 쓸 수 있겠지만 지금 내 현 상황에서 비추어 봤을 때 처음에만 고생하면 나중에 훨씬 편해질 거 같다.

 

3. 한 컴포넌트에는 한 개의 기능만

물론 이것이 정답이 아닐 수도 있겠지만 몸으로 느낀 것은 한 컴포넌트의 한 개의 기능만 있는 것이 좋아 보인다.

예를 들어 게시글 상세 페이지를 만든다 했을 때, 북마크 기능, 지원하기 기능, 댓글 기능 등등.. 기능별로 나눠서 관리해야

나중에 수정할 기능만 톡톡 골라서 수정할 수 있으니 유지보수에 용이할 것 같다는 생각이 들었다.

내 생각이 맞다면 앞으로는 한 컴포넌트에는 한 개의 기능만 넣도록 할 생각이다.

 

4. 2~3번 이상 중복되는 코드는 재사용이 가능하도록!!

메인 프로젝트를 진행하면서 아 이거 재사용 가능하도록 만들고 싶은데... 어떻게 안되려나 하면서 계속 스트레스를 받았었다.

시간이 부족할까 봐 결국 재사용할 수 있도록 만들지는 못했지만 프로젝트 끝나고 프리온보딩을 하면서도 내내 재사용되도록 빨리 만들고 싶다..라는 생각이 좀 컸었다. 그때는 스트레스를 받은 이유가 단순히 이쁘지 않고 썼던 코드 또다시 쓰는 게 짜증이 났었는데,

리팩토링을 하면서 들었던 생각은 일일이 찾아가면서 다 수정을 해야 된다는 것이었다. 현시대에 맞지 않는 행동이었던 거 같다...

 

물론 2,3번 쓰이는 코드는 무조건 재사용이 되도록 만들지는 않아도 되겠지만, 나중에 그 코드가 더 쓰이게 되면 코드가 더 복잡해져 나중에는 또 유지보수가 어려워질 것 같단 생각이 들었다.

따라서 웬만하면 2~3번 혹은 나중에 또 쓰일 것 같은 코드가 생기면 재사용성을 염두하면서 작성해야겠다.

 

5. React-Query는 서버의 값들과 연관된 라이브러리이다.

리팩토링을 진행하기 전에 나는 react-query는 무조건 쓰면 좋은 거 아닌가? 하면서 api 호출 관련된 건 죄다 react-query로 바꿨었는데, 크나큰 착오였다. 예를 들어 게시글 작성 같은 폼을 한꺼번에 보내야 하는 로직이 있는데, 이 하나하나의 state들을 react-query로 관리한다는 게 말이 안 됐었다. 물론 백엔드 측에서 하나하나 관리할 수 있게 만들어주면 가능은 하겠지만, 굳이?라는 생각이 들었다.

따라서 서버와 즉각적인 피드백이 가능한 것들을 react-query로 사용하는 게 바람직해 보인다.

 

앞으로는 react-query는 서버 단에서의 데이터들을, react나 store에서 클라이언트 단에서의 데이터들을 관리하도록 만들 생각이다.

 

6. CS 이해도도 굉장히 중요하다.

 이번에 크게 느낀 것이 CS 지식이 굉장히 중요하다는 것이었다. JavaScript의 동작 원리나 React의 동작 원리를 정말 정확하게 이해하고 있는 게 아니다 보니 이게 왜 안돼? 이게 왜 이거야?라는 게 굉장히 많았다. 

예를 들어 useEffect를 사용하려면 virtual DOM을 이해하고 있어야 한다던지, useCallback이나 useMemo 같이 메모이제이션을 왜 써야 하는 건지, 렌더링의 순서 등 생각보다 알아야 할 것들이 많았다.

처음 공부했을 때는 단순히 react 쓰면 좋대~라고 해서 썼었지 왜 좋은지에 대해서는 정말 깊게 생각은 안 했었던 것 같다.

꾸준히 찾아보고 있지만 정리가 안된 느낌이다.

 

앞으로 CS 공부는 꾸준히 해야겠다는 생각이 들었다.