저번 시간에 리팩토링이 아직 덜 끝났다고 분명 말씀드렸다. 맞다.
ㅋㅋㅋㅋ 그래서 이번을 최종편으로 잡고 마무리 구조와 더불어, 간단한 소감으로 얘기를 마치고자 한다.
🔬 1. 또 보니까 더 있네...
현재 필자의 프로덕트 카드의 전체 컴포넌트 구조다. 그런데 뭔가 여기서 찝찝함이 느껴지지 않으시는가? 그도 그럴 것이 멘토 재준님을 비롯하여 다른 팀원들도 굳이 재사용되지 않는 컴포넌트를 저렇게 나눠야 할 필요성에 대해 의문을 던졌다.
그 의문의 불씨는 내게 의구심이라는 불에 기름을 부었다...
🗜 2. 최대한 효율적인 컴포넌트 사용을 하자!!!
생각을 곰곰이 해 보니, 굳이 저렇게 나눠 놓고 컴포넌트로 따로 뺄 필요가 없었다.
물론, 재사용 된다면 파일화 시켜 따로 나눠 두는 것이 좋지만, 그 역시도 이렇게까지 할 필요가 없었다. 더군다나 프롭스도 동일하게 부모로부터 받고 있는데, 굳이 저렇게 반복된 프롭스 사용도 문제라는 생각이 또 들었다.
그래서 바로 프로덕트 카드 자체를 하나의 컴포넌트로 만들고 기존에 컴포넌트로 나눠진 요소들을 다 저기에 넣기 시작하는 최종 공사를 구조화를 시작했다.
👷🏻3. 최종 공사 착공!
먼저, 필요하고 중복되는 프롭스를 부모 컴포넌트인 리스트에서 받아오기 위해 프롭스 정리를 했고, 이후 필요한 이벤트 핸들링 함수와 스테이트 문들을 정리해서 상단에 선언해 줬다.
이후, 리턴 값으로 랜더링되는 html 구조를 적어줬다.
참고로, 라이크 버튼은 기존에 사용하던 외부 컴포넌트 파일구조라서 임포트만 시켜서 사용해 줬다.
❓4. 과연 현업에서도 이렇게 한 군데 다 모을까?
막상 이렇게 끝내려니, 아쉬움이랄까 풀리지 않는 의문이 들었다.
현업에서는 과연 어떻게 컴포넌트를 구조화 해 놓고 사용할까?
그래서 이건 현직 개발자인 멘토 재준님께 다시 궁금증을 던졌다. 그는 현답을 다시 알려주셨다.
현업에서는 보통 다 나눠서 쓰긴 해요. 그 이유는 타입 스크립트를 쓰면, 이렇게 프롭스 공통으로 처리되는 것이 아니라서 타입을 지정해서 써주게 됩니다. 그래서 보통은 타입 지정을 위해 하나의 파일에 하나의 컴포넌트만 들어오도록 해 놓아야 해요^^
그런데, 회사의 사정에 따라 그건 가변적인 거라, 회사가 개발이 급해서 타입 스크립트를 안 쓴다고 하면, 지금처럼 하나의 파일에 재사용하지 않으면 합쳐놓고 써도 상관은 없습니당~
이때 기존에 팀원들 간의 논쟁이나 얘기했던 부분이 머리를 스쳐지나가면서 정리되는 느낌이 확 들었다.
🗂 5. 그러면 마지막으로 파일 정리 GO GO!
그래서 필자는 바로 실행에 옮겼다. 결론적으로 리스트 컴포넌트 하나만 남기고, 소팅버튼 컴포넌트와 카드랩퍼 컴포넌트는 따로 리스트 폴더 안에 파일화 시켰다.
그리고는 리스트 컴포넌트가 결국 랜더되는 화면이니까 다시 컴포넌트를 임폴트 시키도록 했다.
결국 최종적으로 이렇게 필자의 길고도 길었던 1차 프로젝트 리팩토링이 일단락 지어졌다.
😊 6. 리팩토링에서 느낀 바.
사실 리팩토링을 처음 생각했을 땐, 뭐 별거 있겠나? 싶었다. 하지만, 하루 하루 내 코드가 너무 별로구나라는 생각을 하나 둘 하게 되었다.
그러면서 코드리뷰가 정말 이래서 중요하다는 것을 다시 절실하게 느끼는 순간이었다.
특히, 이번 리팩토링은 개발자적 관점에서 조금은 더 깊이 생각하게 된 시간이었다. 처음 비효율적인 코드라고 생각한 단 한줄의 코드가 이렇게 눈 덩이처럼 구조 자체를 바꿀 수도 있다는 것을.... 해 보기 전에는 전혀 몰랐다.
하나의 문제가 아닌 이제는 조금 더 전체 코드의 구조를 어떻게 효율적이고 유지보수 관리 측면에서 바라보는 것이 좋을 지에 대한 고민을 해야겠다.
물론 아직 필자는 개발을 시작한 지 기껏해야 3달 차다. 그러다 보니... 완벽한 클린 코드를 짤 수는 없다고 생각한다. 그렇지만, 초반에 가진 이 습관을 꾸준히 현업에 들어가서도 계속 지켜야만 좋은 개발자가 될 수 있다는 것을 확신한다. 좋은 개발자에 대한 생각을 마지막 한줄 평으로 남기면서 길었던 1차 프로젝트 리 팩토링 회고를 마치겠다.
좋은 개발자란? 단순히 구현하는 코드에서만 그치는 것이 아닌, 이후에 유지 보수가 좋은 코드로 철저하고 끊임없이 고민하는 사람이지 않을까...
