Fish-it 프로젝트 회고록

Fish-it?

Fish-it 프로젝트는 지난 3월 ~ 8월경에 거쳐 진행한 프로젝트입니다.

이 프로젝트는 인터넷 쇼핑몰 사이트의 가격정보를 크롤링하고 이를 실시간으로 보여주며 동시에 가격히스토리에 데이터를 저장하고 사용자에게 등록한 가격대의 알림을 보내주는 서비스로써 구체적인 내용은 하단 링크에 첨부해두었습니다.

아무래도 처음 React & SpringBoot를 다루었기 때문에 공부와 개발을 병행하며 진행했고 동시에 프로젝트를 마치고 난 지금의 입장에서 아쉬웠던 점 및 좋았던 점을 정리하고 돌아보고자 합니다.

github

medium

진행 과정

학업과 프로젝트 기간이 곂처 병행하며 진행했기 때문에 역할을 분배하고 매주 토요일에 만나 진행 상황을 공유하고 프로젝트의 방향성과 향후 계획을 정하는 방식으로 진행하였습니다.

초기에는 Spring Boot를 사용한 로그인 부분의 코드를 구현하였으며 이후에는 프론트엔드로 넘어가 팀원과 React를 사용해 협업하였고 마지막으로 배포까지 전반적인 과정을 다루는 과정을 거쳤습니다.

특히 Notion을 활용하여 작업 내용을 기록하고 관리하였습니다.

좋았던 점 & 얻은 것

1. Swagger & Mock Api를 사용한 협업

   백엔드 api를 개발하면서 프론트엔드 팀원분께 만든 api를 설명하거나, 혹은 팀원분께서 만들어주신 api 내용을 문서를 보고 확인하며 프론트에서 테스트 하는 작업을 겪으며 초기의 문서로 작성한 api내용의 관리가 좋지 않다는 것을 느꼈습니다.

   특히 api의 내용이 수정된다면 하나하나 수동으로 문서의 내용을 다시 바꿔야 했으며 오타 및 실수 또한 바로 잡아줄 수 없었기 때문에 이런 부분에서 향후 도입했던 Swagger의 사용이 개발에 있어서 능률을 높여준다고 몸소 체감하였습니다.

   또한 프론트엔드와 백엔드 동시에 개발에 들어갔을 때 PostMan의 Mock Api를 사용하여 미리 응답 값을 가져와 테스트 할 수 있었는데 이러한 부분또한 개발을 하는 데 있어서 능률을 높여주는 하나의 좋은 툴이였습니다.

   아무래도 혼자 개발을 하는 것이 아니기 때문에 프론트엔드와 백엔드 사이의 api양식 또한 효과적인 방법으로 관리해야 할 필요성을 느낄 수 있었던 것 같습니다.

2. Google Coding Style & pretter의 도입

   코드를 짜는 방식은 개인마다 차이가 두드러지는 부분이라고 생각합니다. 띄어쓰기나 변수명 그리고 들여쓰기 하는 횟수마저도 각각의 스타일에 따라 구현하는 방식이 다르기 때문입니다. 하지만 협업을 하고 서로의 코드를 보며 피드백을 주고받기 위해 이런 부분 하나하나 통일하는 것이 되게 중요하다고 느꼈습니다.

   Google Coding Style 는 이런 문제점 해결을 위해 백엔드에서 사용했던 녀석입니다.

   적용 파일을 넣고 팀 내에서 정의한 Tap size, Indent 등의 설정을 맞춰 사용하면 저장 시 자동으로 규격화된 들여쓰기 및 개행문자를 넣어 코드의 가독성을 높이는 데 정말 많은 도움이 되었습니다.

   prettier 의 경우 React에서 사용하였는데 마찬가지로 저장 시 들여쓰기, 세미콜론 등을 자동으로 붙여줍니다.

3. github를 활용한 PR & 코드리뷰 진행

   저희 팀에서는 각자 작업하던 내용을 merge하기 위해서는 적어도 한 명 이상의 팀원의 리뷰가 필요했습니다.

   사실 팀 단위로 코드를 구현하는 경험은 많지 않았기 때문에 팀원분의 코드 리뷰를 통해 실수나 잘못된 방향의 설계 또한 모두 점검받아 수정할 수 있었고 진행 상황 또한 PR내용을 바탕으로 보다 쉽게 확인할 수 있었습니다.

   동시에 보다 좋은 설계를 위한 의견공유 및 공부 내용을 공유할 수 있어서 개인적으로 가장 값진 부분을 이 부분을 통해 얻어갔다고 생각합니다.

   

아쉬웠던 점

1. 팀원의 구현 내용을 모름

   사실 프론트 , 백엔드, Heroku를 통한 배포까지 전반적으로 프로젝트에 참여한 것은 맞지만 실질적인 크롤링, gitAction을 통한 자동배포, 그리고 jsoup을 활용한 크롤링 주기 설정과 같은 일부분은 전혀 이해하지 못한채로 넘어갔습니다. 핑계지만 이해가되지 않는 부분은 집요하게 공부하는 게 아니라 해야 할 일에 집중 하다보니 아예 찾아보지도 않고 그냥 넘어갔는데 이런 자세는 좋지 않았다고 생각합니다.

2. React의 package관리 방식

   저희 팀에서는 yarn 과 npm 모두를 사용하여 패키지를 관리하거나 설치하였습니다.

   사실 초반에는 문제가 없었는데 이를 통일하지 않고 사용하다 보니 서로 간의 패키지 설치 오류로 인해 고생했던 경험이 있었습니다.

   뒤늦게 하나를 선택해서 통일하게 되었는데 이런 사소한 것 하나하나가 개발에 좋지 않은 영향을 미칠 수 있다는 것을 인지하고

   초기부터 하나로 통일하여 진행해야겠다고 다짐하게 되었습니다.

마치며

시간에 쫓기며 매주 해야 할 일을 하다 보니 어느새 마무리까지 짓게 되었습니다.

정말 다행히도 좋은 팀원과 리더님을 만나서 방향성을 잘 잡고 협업과 관련된 여러 기술과 태도를 배우게 되는 경험이었다고 생각합니다.

아무래도 직접 팀원과 협업하며 본격적으로 개발했던 경험은 처음이라고 할 수 있기 때문에 더더욱 많이 배워가지 않았나 싶습니다.

이번 경험을 살려 다음에는 한번 리더를 맡아 제가 배웠던 경험과 노하우를 팀원분들께 공유하고 싶다는 생각도 들었습니다.