정신없이 2주간의 팀프로젝트가 끝이났다. 결론부터 말하자면 조금 아쉬우면서도 생각해보면 얻어간게 진짜 많았던 것 같다. ㅎㅎ...🥲
시간이 더 흘러서 2주동안 프로젝트를 진행하면서 까먹기 전에 내가 배웠던 점, 좋았던 점, 아쉬웠던 점, 앞으로의 목표 등을 정리해보자!

해당 프로젝트의 위키는 여기서 볼 수 있다.

먼저, 좋았던 점🍎

재사용성을 높힌 작은 단위의 컴포넌트 개발

프론트엔드에서 리액트 컴포넌트 단위로 개발을 하여 재사용성을 높이니 개발이 편했다. 작은 단위 컴포넌트로 개발하면 어떤 점이 편한지 느낄 수 있었다.
예를 들어 기존에 클론 코딩을 진행하거나 혼자 토이프로젝트를 한다고 쳤으면 아마 페이지 단위로 작업하면서 거기서 필요한 작은 단위의 엘리먼트(버튼, 인풋, 라벨 등등)들이 필요했다면 그때그때마다 만들면서 개발을 했을 것이다.

하지만, 이번에는 프로젝트 시작전부터 컴포넌트를 최대한 재사용해보는 쪽으로 목표를 두고 서비스 전체에서 쓰일 공통 컴포넌트와 기능들을 미리 생각해서 개발해보기로 했다. (팀장님 캐리 감사합니다.) 그러하여 페이지마다 당연하게 쓰일 수 밖에 없는 엘리먼트들을 미리 다 만들어두고 하니 페이지에서는 import로 그때그때 가져와서 쓰면 됐다. 개발이 너무 편하다고 생각했다.

git, github를 통한 협업 과정의 전반적인 이해

처음으로 팀프로젝트를 진행하면서 전체적으로 개발이 어떻게 진행되며 git, github 등 의 버전관리 시스템의 장점을 활용하여 프로젝트 진행의 전체 흐름을 파악할 수 있었다.
이것 또한 프로젝트 시작전 미리 깃허브 페이지를 파서 프론트엔드 팀원간에 협업 flow를 미리 연습해볼 수 있었다.
git pull 부터 git checkout 등의 기능으로 새로운 브랜치를 만들어 각자의 기능을 개발하고 dev브랜치는 각각의 local에서 최신화와 remote에 백업용으로 두고 feature/issueNumber-workingPage 형식의 브랜치를 자신의 origin에 push하고 origin 에서 upstream 으로 PR을 날리는 형태로 작업했다.
이때, 자신이 PR을 날린 브랜치와 upstream의 dev 브랜치가 충돌이 일어나는 경우 해당 블로그를 참고하여 git pull --rebase 를 통해 각자의 로컬에서 충돌을 해결한 뒤 다시 PR을 날리는 형태로 진행했다.
이 외에 단순히 git add ., git commit -m만으로 git을 관리하던 습관에서 팀장님이 공유해주신 git add -p, git commit -v 와 같은 새로운 기능들을 사용했을때 얻게 되는 이점들에 대해서도 알게됐다.

tailwind css의 활용

tailwind css 와 twin.macro 등의 CSS 스타일링 전처리기를 통해 극한의 효율성을 느낄 수 있었다. 이 덕분에 코드도 짧아졌다.
스타일링에 있어서 몇가지 대안이 있었지만 (특히 styled-component) 우리는 tailwind를 선택하게 됐고 tailwind 자체로도 강조하고 있는 utility-first 라는 말에 많은 공감을 하면서 사용을 했다.
기존 혼자 프로젝트를 진행할 때에는 개인적으로 자동적으로 스스로를 모듈화해줘서 컴포넌트별 className을 공통적으로 써도 문제가 없는 PostCSS를 활용했었으나(CRA가 기본으로도 깔아주고 얼마나 좋아) 컴포넌트를 작성한 코드와 우선 파일을 분리하고 그 파일들을 폴더로 관리하면서 생기는 불편함(?) 특히, 창에 너무 많은 파일들이 열려있고 컴포넌트 내의 className의 이름을 비교해가며 작성해야 되는 부분에서 좀 불편함들 느끼고 있던 찰나, 컴포넌트 내에서 스타일링을 해결하면서 동시에 css의 코드량을 엄청나게 줄일 수 있다는 것을 보고 좀 써보고 싶다는 생각이 많이 들었다.
그리고 써본 결과는 절대 후회하지 않는다. twin.macro 와 함께 사용하며 필요할 때는 인라인으로 커스텀 CSS로 적용해도 문제가 없어서 사실 CSS는 정말 만족했던 것 같다.

Airbnb ESLint 사용

이 부분도 시작 전 팀회의를 통하여 Airbnb의 eslint 를 사용해보기로 하였고, 결과는 만족이였다.
팀원들간의 비슷하면서도 다른듯한 코드를 마치 한사람이 짠거같이 유지할 수 있었고 쓸데없는 변수 선언이나 import가 있을때 미리 error를 띄워줘서 잔버그나 안정성등에서 이점을 얻는 것 같다.
왜 많은 개발자들이 ESLint를 활용하는지 느낄 수 있었다.

PropTypes를 활용한 prop 타입검사

기존 리액트를 활용하면서 prop의 타입을 검사해본 적이 없었는데 프로젝트 중에 처음으로 활용해보면서 개발의 안정성이 좋아질 수 있다는 걸 알았다. 왜 타입스크립트를 쓰는지 알 것 같다.
특히, 백엔드 개발자가 서버구축 작업을 하는동안 프론트에서는 더미데이터를 활용하여 미리 prop등에 데이터를 받아봐야하는 상황이 생겼는데 defaultProps를 활용하여 컴포넌트에 미리 prop도 내려보면서 개발할 수 있어서 매우 편리했다.

이제, 아쉬웠던 점🧐

• 아무래도 시간이 부족하다보니 모듈쪽에 구현을 제대로 못해본게 아쉽다. 파이널때는 작은 파트의 모듈이더라도 직접 구현해보고 싶은 생각이다.
• 모듈쪽의 구현을 못했다보니 백엔드와의 데이터를 주고받는 부분도 경험해보지 못해서 좀 아쉬웠다. 백엔드와 데이터를 주고받으면서 어떤 부분에 권한이 필요한지 어떤 요청이 들어오는지 눈으로 직접 보면서 개발했으면 더 재밌었을 것 같단 생각을 많이 했다. 좀 간접적으로 느낀게 많아서 아쉬웠다.
• 리덕스를 많이 사용해본 적이 없다보니 좀 버벅거린 것 같다. 그래도 prop을 밑으로 안내려줘도 되는게 신세계인걸 좀 체감해서 리덕스는 꼭 써야겠다.
• 단순히 기능을 구현하기위한 코드작성이 아닌 좀 깔끔한 코드를 작성할 수 있으면 좋겠다는 생각을 많이했다.
• 팀원들과 태스크 분배 및 기능구현에 대한 소통을 많이 못한 것 같아서 아쉬웠다. 기간이 아무래도 좀 짧다보니 후딱후딱 해야하는 것 때문에 이해했지만 파이널때는 좀 더 소통하면서 같이 만들어가는 프로젝트로 만들 수 있었으면 좋겠다.

마지막으로, 목표 혹은 시도할 점👋

• 최소한 로그인 페이지 정도의 구현은 내가 직접 해보고 싶다. 파이널까지 시간이 좀 있으니 그때까지 파이널을 위해서 좀 공부해볼 생각이다.
• 깔끔한 코드작성을 위해 클린코드 책도 읽어봐야겠다. 물론 이건 나중이겠지만...? 우선은 프로젝트에 집중하자.
• 리덕스 툴킷의 장점을 좀 많이 들어서 파이널때는 리덕스 대신 툴킷을 좀 활용해보고 싶다. 슬라이스라는 개념을 사용해서 액션과 리듀서 등을 쉽게 만들어준다고 했던 것 같은데...어쨌든 리덕스의 불편한 점들을 리덕스팀에서 개선했다고 들었다. 공식문서를 보면서 다시한번 스터디 해보자.
• 팀원들과 태스크분배를 정확히 해놓고 프로젝트를 시작해야겠다는 생각을 많이했다. 아무래도 오프라인이 아닌 온라인환경에서 코드를 치기 시작하면 소통하기 어려운 문제가 확실히 발생하는 것 같다. 기획과 태스크분배의 중요성을 좀 느낀 첫 프로젝트였다.