정신없이 2주간의 팀프로젝트가 끝이났다. 결론부터 말하자면 조금 아쉬우면서도 생각해보면 얻어간게 진짜 많았던 것 같다. ㅎㅎ...🥲
시간이 더 흘러서 2주동안 프로젝트를 진행하면서 까먹기 전에 내가 배웠던 점, 좋았던 점, 아쉬웠던 점, 앞으로의 목표 등을 정리해보자!
해당 프로젝트의 위키는 여기서 볼 수 있다.
프론트엔드에서 리액트 컴포넌트 단위로 개발을 하여 재사용성을 높이니 개발이 편했다. 작은 단위 컴포넌트로 개발하면 어떤 점이 편한지 느낄 수 있었다.
예를 들어 기존에 클론 코딩을 진행하거나 혼자 토이프로젝트를 한다고 쳤으면 아마 페이지 단위로 작업하면서 거기서 필요한 작은 단위의 엘리먼트(버튼, 인풋, 라벨 등등)들이 필요했다면 그때그때마다 만들면서 개발을 했을 것이다.
하지만, 이번에는 프로젝트 시작전부터 컴포넌트를 최대한 재사용해보는 쪽으로 목표를 두고 서비스 전체에서 쓰일 공통 컴포넌트와 기능들을 미리 생각해서 개발해보기로 했다. (팀장님 캐리 감사합니다.) 그러하여 페이지마다 당연하게 쓰일 수 밖에 없는 엘리먼트들을 미리 다 만들어두고 하니 페이지에서는 import
로 그때그때 가져와서 쓰면 됐다. 개발이 너무 편하다고 생각했다.
처음으로 팀프로젝트를 진행하면서 전체적으로 개발이 어떻게 진행되며 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 와 twin.macro 등의 CSS 스타일링 전처리기를 통해 극한의 효율성을 느낄 수 있었다. 이 덕분에 코드도 짧아졌다.
스타일링에 있어서 몇가지 대안이 있었지만 (특히 styled-component) 우리는 tailwind를 선택하게 됐고 tailwind 자체로도 강조하고 있는 utility-first
라는 말에 많은 공감을 하면서 사용을 했다.
기존 혼자 프로젝트를 진행할 때에는 개인적으로 자동적으로 스스로를 모듈화해줘서 컴포넌트별 className
을 공통적으로 써도 문제가 없는 PostCSS를 활용했었으나(CRA가 기본으로도 깔아주고 얼마나 좋아) 컴포넌트를 작성한 코드와 우선 파일을 분리하고 그 파일들을 폴더로 관리하면서 생기는 불편함(?) 특히, 창에 너무 많은 파일들이 열려있고 컴포넌트 내의 className
의 이름을 비교해가며 작성해야 되는 부분에서 좀 불편함들 느끼고 있던 찰나, 컴포넌트 내에서 스타일링을 해결하면서 동시에 css의 코드량을 엄청나게 줄일 수 있다는 것을 보고 좀 써보고 싶다는 생각이 많이 들었다.
그리고 써본 결과는 절대 후회하지 않는다. twin.macro
와 함께 사용하며 필요할 때는 인라인으로 커스텀 CSS로 적용해도 문제가 없어서 사실 CSS는 정말 만족했던 것 같다.
이 부분도 시작 전 팀회의를 통하여 Airbnb의 eslint 를 사용해보기로 하였고, 결과는 만족이였다.
팀원들간의 비슷하면서도 다른듯한 코드를 마치 한사람이 짠거같이 유지할 수 있었고 쓸데없는 변수 선언이나 import가 있을때 미리 error를 띄워줘서 잔버그나 안정성등에서 이점을 얻는 것 같다.
왜 많은 개발자들이 ESLint를 활용하는지 느낄 수 있었다.
기존 리액트를 활용하면서 prop의 타입을 검사해본 적이 없었는데 프로젝트 중에 처음으로 활용해보면서 개발의 안정성이 좋아질 수 있다는 걸 알았다. 왜 타입스크립트를 쓰는지 알 것 같다.
특히, 백엔드 개발자가 서버구축 작업을 하는동안 프론트에서는 더미데이터를 활용하여 미리 prop등에 데이터를 받아봐야하는 상황이 생겼는데 defaultProps
를 활용하여 컴포넌트에 미리 prop도 내려보면서 개발할 수 있어서 매우 편리했다.