개인 프로젝트를 진행하면서, 나와 유사한 상황인 취준생들의 포트폴리오를 살펴보니 '왜 다른 사람들처럼 코드를 빨리 작성할 수 없는 걸까?' 라는 고민이 들었다. 프론트엔드 분야에서 취준생들은 보통 1~2주에서 최대 한 달 정도의 시간을 투자하여 하나의 프로젝트를 완성하는 것으로 보였는데, 그에 비해 나는 하나의 컴포넌트를 완성하는 데 일주일이나 걸린다는 사실에 의아함과 문제 의식을 느꼈다.
나의 문제
나는 코드 작성 전에 디자인에서 비슷한 구조가 없는지 확인하고, 비슷한 구조들을 모아 하나의 컴포넌트로 어떻게 구현할 수 있을지 고민하며 컴포넌트 구조를 설계한다. 그리고 공통 컴포넌트 구조가 완성되면 코드 작성을 시작한다. 이 과정에서 컨퍼런스나 여러 아티클에서 소개하는 "컴포넌트 설계", "클린 코드" 등 유경험자들이 말하는 좋은 컴포넌트 개발 방식을 접목시키고자 노력했다.
하지만 나는 유경험자들이 말하는 좋은 컴포넌트 개발 방식을 바로 접목시킬 수 없는, 구현 경험이 부족한, 그야말로 취준생이다. 리액트로 실제로 구현해본 경험이 적고 그들이 말하는 불편함을 느껴보지 못했기 때문에 컴포넌트 구조 설계에 어려움을 겪고 고민하는 시간만 늘어났다. (기술에 매몰된 안 좋은 케이스...)
- 구현 경험이 적기 때문에, 바로바로 컴포넌트의 구조를 떠올릴 수 없다.
- 불편함을 직접 경험해보지 못했기 때문에, 좋고 나쁨을 판단할 수 없다.
그러니까 나는 아직 컴포넌트의 설계를 생각하고 유경험자들의 패턴을 따라할 단계가 아니라는 것이다...
개선
결국 잘못된 구현 방식을 개선하기로 결심하고, 일명 "무식하게 코드 짜기" 규칙을 정했다.
- 무식하게 코드 짜기
- 비슷한 UI가 많이 사용되더라도 일단 당장 눈 앞의 것만 구현하는 데 집중한다.
- 데이터, UI 등 역할 분리를 고려하지 않고 일단 구현한다.
- Props drilling의 끝을 달려보자.
- 리팩토링 하면서 고민하기
먼저 무식하게 짜고 모든 구현이 끝난 뒤 리팩토링을 하면서 어떻게 개선할 수 있을지 고민해보는 것, 그게 새로운 방식이었다.
리팩토링 방법
리팩토링도 단계를 나눠서 진행했다.
2-1. 모든 컴포넌트에 컴포넌트가 하는 모든 역할 나열하기
가장 먼저 모든 컴포넌트마다 컴포넌트가 하는 역할을 나열할 때는 위 사진처럼 컴포넌트 선언부의 상단에 NOTE 캡션으로 ShareButton이 하는 역할을 모두 적었다. 사소한 것부터 핵심까지 전부 작성하여 해당 컴포넌트가 어떤 역할을 수행하는지 파악하는데 중점을 두었다.
2-2. 리팩토링 아이디어 작성하기
모든 컴포넌트마다 역할을 작성했으면, 이제부터 TODO 캡션으로 리팩토링 아이디어를 작성했다.
모든 역할을 작성해두었기 때문에 UI와 데이터 분리를 생각하기도 쉬웠고, 다른 컴포넌트에도 동일한 처리 로직이 있는지 파악하기도 쉬워 리팩토링 아이디어를 작성하는데 수월했다.
2-3. 작성한 아이디어 따라 리팩토링 진행
2-2에서 작성한 아이디어로 리팩토링을 차근차근 진행하면 끝이다.
결과
1번의 무식하게 코드 짜기를 하니 개발 속도가 눈에 띄게 빨라졌다. 뿐만 아니라 당장 눈 앞에 무언가가 그려지고 동작을 하니 떨어졌던 자신감도 생겼다. 물론 빠른 구현에만 목적을 뒀기 때문에 지저분하고 중복되는 코드가 많아 답답한 마음이 들었지만, 어차피 리팩토링한다는 생각에 쉽게 구현할 수 있었다.
가장 많은 깨달음을 얻은 것은 리팩토링 과정에서 였다. 구현이 전부 완료된 이후에 컴포넌트 분리를 하니 어떤 기준으로 분리가 돼야 하는지 보다 명확해졌고, 유경험자들이 말하는 '좋은 컴포넌트'가 왜 좋은 지를 머리로만 그렇구나 이해하는 것이 아니라, 아~! 이래서 이게 좋은 거였군 하고 경험으로 이해할 수 있었다.
아직 이해할 수 있는 범위가 좁아서 엄청난 리팩토링을 했다! 라고 할 수 없지만, 이번 과정을 거쳐 한 단계 나은 개발을 할 수 있었고 기술에 매몰되지 말고 역시 기본부터 충실해야 한다는 것을 깨달았다. 앞으로도 무식하게 코드를 짜고, 리팩토링을 진행하면서 더 많은 고민을 하는 것으로 경험을 쌓아가야 겠다.
