많은 수의 포트폴리오보다 협업을 얼마나 잘할 수 있는가. 어떤 코드를 썼는가, 어떤 코드 리뷰를 작성했는가 등 속 알맹이가 더 중요하다고 생각한다. 어떤 기술을 사용했을 때 내가 해당 기술을 얼마나 알고 사용했는지가 중요하다. 즉, 단순히 이 기술을 사용할 줄 안다는 관점으로 접근하는 게 아니라 기본기에 충실한 모습이 중요하다.
리팩토링 프로젝트 배경
리팩토링의 필요성은 현업 개발자분들도 매번하는 고민이라고 생각합니다.
저는 React 학습 후 처음 만들어보는 팀 프로젝트였기 때문에 제가 사용하는 기술을 제대로 사용했는지 점검할 필요성을 느꼈고,
더 나아가 코드의 생산성과 유지보수성을 올릴 수 있는 역량을 쌓기 위해 리팩토링 작업이 진행했습니다.
많은 기술 스택 중 React를 선택한 이유
React를 React로 리팩토링하는 게 가장 효율적이라고 생각했고, React 자체가 생산성과 유지보수성이 굉장히 높다고 생각하고 있습니다.
구직자의 입장에서도 React를 찾는 공고가 많기 때문에 그런 부분도 함께 고려했습니다.
상태 관리
나만의 작은 설렘 ver 1에서의 상태 관리는 Redux Toolkit을 사용했습니다.
Redux가 굉장히 오래되긴 했지만 가장 많이 사용되고 있고, 팀원들도 큰 기술적인 장벽 없이 바로 사용할 수 있는 기술이라고 생각했습니다.
나만의 작은 설렘 ver 2에서의 상태 관리는 React Query를 적용할 계획입니다.
Redux의 보일러 플레이트를 개선한 Redux Toolkit을 사용했지만 서버에서 가져온 데이터를 Redux store에 저장하고 관리하는 행위가 불편하게 느껴졌습니다.
서버 데이터가 서버를 떠나 store에 저장되는 이상 store는 원본이 아니라 서버 데이터의 복사본일 뿐이기 때문에 최신 상태라고 보기 어려웠습니다.
점진적 전환 방법
공통 컴포넌트를 구현하면서 User Flow에 따라 페이지 작업을 시작했고, 코드의 가독성과 생산성이 떨어진다고 생각한 로직부터 개선했습니다.
코드 리뷰를 하는 이유
코드에 대한 책임이 그 코드를 만든 사람 혼자에게 있지 않고 팀원 모두에게 있다는 문화를 정착시키고 싶었습니다.
또한 제 실력의 부족함을 인정하고 코드 리뷰를 통해 팀원들의 좋은 코드를 기록하고 프로젝트에 적용하며, 실력을 높이고 싶었습니다.
현재 내 실력이 다른 팀원들에 비해 부족하다는 것을 인정하고
코드 리뷰를 통해 팀원들의 좋은 코드를 기록하고 프로젝트에 적용하며, 실력을 높이는데 집중하자.