컴포넌트 세분화(프로젝트 구조)와 commit의 중요성

이번에 원티드 프리온보딩 프론트엔드 코스에 지원했다가 보기좋게 떨어졌다. 변명을 하자면 코드스테이츠 메인프로젝트를 하루 3시간 자면서 진행했던 터라, 휴식이 필요했다. 그래서 결국 마감 하루 전날 새벽에 부랴부랴 완성하여 제출하였고 결과는 불합격이였다. 떨어지고 나서 다른분들이 제출한 코드를 보니 내가 고칠점이 많이 보였다. 그래서 리팩토링을 진행하였고, 내가 개선한 점과 배운점을 정리해 보려고 한다. 

 

 

1. 컴포넌트 세분화

 

처음 프로젝트 구조

리팩토링 전 구조에서는 페이지와 컴포넌트를 나눴지만 사실상 컴포넌트에는 TodoItem 하나뿐이였고, 나머지는 pages 폴더 안에 있는 Sign페이지와 Todo페이지에서 모든 로직을 다 작성하였다. 컴포넌트 추상화를 통해, 하나의 독립된 컴포넌트들이 모여 완성되는 형태로 개발을 하지 않고, 하나의 페이지에 기능과 로직을 다 때려넣는 식으로 개발을 한 셈이다. 

 

위처럼 TodoList를 개발한다고 하였을때 하나의 컴포넌트에 모든 기능을 다 넣기 보다 

이렇게 Title, Input, TodoList, TodoItem 등으로 분리하고 역할에 따라 더 작은 컴포넌트로 나누어 개발하면 재사용성도 좋아지고, 컴포넌트 하나가 최소 하나의 기능을 담당하기 때문에 코드가 간결해지고 한눈에 파악하기 훨씬 쉬워진다. 

나는 간단한 기능구현이라 생각했기에 컴포넌트 추상화나 분리해서 개발하는식으로 생각하지 않고, 그냥 되는대로 개발했던 것 같다. 

결과적으로 똑같이 기능구현이 된다고 하더라도, 실제로 현업에서 혹은 큰 규모의 프로젝트를 진행한다고 했을때, 이러한 습관은 매우 안좋게 작용할 가능성이 높다. 앞으로는 아무리 작은 프로젝트를 진행한다 하더라도, 항상 먼저 추상화하고 구조를 생각하고 고민한 뒤에 작은 단위의 컴포넌트부터 개발하도록 하자!

 

리팩토링후 구조는 다음과 같다. 

Sign을 Auth로 바꾸고 components폴더에 따로 담는것이 아니라 Auth페이지와 Todo페이지 안에 필요한 컴포넌트들을 담았다. 

Auth페이지로 예를 들면 Auth페이지 안에 AuthForm이 위치하고 그 안에 AuthInput이 위치하는 이러한 형태이다. 

각 페이지를 구성하는 컴포넌트들을 components 폴더에 넣을지 아니면 pages 폴더 안에 넣을지 이부분은 현재도 고민중인 부분인데, 프로젝트의 특성에 따라 달라질 수도 있겠다고 생각이 든다. 하지만 현재로서는 페이지를 구성하는 작은 단위의 컴포넌트들이 한 폴더 안에 위치하는 것이 작업할때도 편하고 보기에도 좋다는 느낌을 받았다. 그리고 컴포넌트 폴더에는 정말 범용적으로 자주 쓰이는 컴포넌트를 넣는것이 현재로서는 좋은것 같다는 생각이 든다. 

 

Todo페이지 또한 이전에는 TodoItem만 분리하였었는데,

Todo 추가 기능을 담당하는 TodoInput컴포넌트, TodoList를 보여주는 TodoList컴포넌트, TodoList컴포넌트를 안의 작은 단위인 TodoItem컴포넌트로 나누었다. 각 컴포넌트들의 역할과 기능을 명확해지다보니 한눈에 파악하기 쉽고 코드가 간결해졌다.

그밖에 style 코드들 또한 따로 빼서 분리해주었다. 

 

Todo컴포넌트로 예를 들면 Todo컴포넌트 밑에 있던 styled-components 코드들을 Todo.Style.jsx로 분리하여

이런식으로 사용하였다. 

이렇게 CSS 코드와, 리액트 코드를 분리하고 나니, 한눈에 명확하게 들어오고 실제로 작업할때도 분리 되어있어 훨씬 편했다.

(분리하고 세분화하자!)

 

리팩토링을 진행하며 리액트를 공부하며 배웠던 추상화, 그리고 단일책임원칙이 떠올랐다. 나는 그렇게 공부해놓고 실제로는 실천하고 있지 않았다. 하지만 이번 기회를 통해 왜 그렇게 컴포넌트별로 나누어 개발하는 것이 좋은지, 어떤 장점이 있는지 확실히 알 수 있었다. 

역시 이론적으로 공부를 아무리해도, 직접 부딪혀보고 깨지고 느끼지 않으면 내것이 될수 없다는 것을 다시한번 느꼈다. 

 

 

2.  commit의 중요성!

이번 과제를 하면서 나는 레퍼지토리를 생성하지 않고 로컬에서 다 완성시킨 뒤에 커밋을 하였다. 물론 하루도 안걸린 작업이였고, 프로젝트도 아닌 단일 과제였기에 그냥 빨리 완성시켜 제출해야 한다는 생각밖에 없었다. 그런데 다른 분들의 레퍼지토리를 보니 총 커밋이 거의 10개 이상이였다. 메인 프로젝트를 진행하면서도 작은 단위로 커밋을 자주하라는 말을 들었었는데, 나는 그러지 않았다. 

지금와서 생각해보면 내가봐도 커밋이 한개밖에 없으면 그냥 복붙해서 완성했다고 생각하거나, 혹은 뭔가 이상하다고 생각이 들것 같다.

commit log는 어떻게 개발을 진행해왔는지 알 수 있는 지표이다. 사람들과 함께 협업하는 대부분의 프로젝트에서 커밋 로그에는 처음 프로젝트 생성부터  완성까지 그 전체 과정이 담겨있다. 그렇기에 커밋하지않고 그냥 로컬에서  계속해서 작업하는 이 습관은, 기록의 측면에서도 좋지 않고, 협업측면에서도 좋지 않고, 나 자신에게도 좋지않다. (커밋을 하지 않으면 어디서 무엇이 잘못됬는지 파악이 어려움)

 

그렇다면 commit은 얼마나 자주 해야 할까? 

이 또한 정답은 없지만 작은 단위로 나누어 하는게 좋다고 생각된다. 

 

예를들어 todoList를 만든다면 

- todoList 컴포넌트 구조 설계 생성

- todoItem 컴포넌트 생성

- todoItem 컴포넌트 로직 작성

- todoItem CSS 작성

- todoInput 컴포넌트 로직 작성

....

등등 수없이 많은 tesk로 나눌 수 있다. 이렇게 잘게 쪼개진 일들을 진행할때마다 커밋을 하는 것이다. 

이렇게 하면 어떠한 문제가 발생하였을때 내가 어디서부터 잘못됬는지 파악하기도 훨씬 수월하다.  

지금 당장에는 귀찮고, 시간도 더 오래 걸리는 것 같아보여도 결국 나중에는 오히려 시간이 절약되고 효율적으로 개발할 수 있는 원동력이 된다고 생각된다. 앞으로는 아무리 작은 프로젝트여도, 프로젝트의 생성부터 완성까지 잘게 쪼개어 생각하고 자주자주 커밋하는 습관을 들이자!