👨‍🚀 팀프로젝트 회고록 - 방갑고

😃 6주간의 팀 프로젝트 회고를 기록합니다. 프로젝트의 짧은 소개와 함께 협업을 하면서 있었던 것들에 대해 작성합니다.

👀 프로젝트 소개

🏠 Project 방갑고

📌 Project 참여 인원 
👉🏻 프론트엔드 3명

👉🏻 백엔드 3명

📌 Project 방갑고 소개
👉🏻 사회 초년생들의 주거비용 부담을 덜어내고자 사용자가 원하는 금액대의 방과 룸메이트를 매칭해 주는 플랫폼 서비스 Project 

💁‍♀️ 대표적인 기능

1. 성향이 맞는 룸메이트 자동 추천 기능 제공
2. 사용자간 룸메이트 매칭이 완료되면 유저 채팅 기능 제공
3. 사용자가 원하는 지역, 기간, 금액, 성별에 맞는 게시글 필터링하여 검색 가능

😀 짧은 프로젝트 구현 기능들

👨‍👨‍👧‍👧 협업을 하면서 느낀것들.

🤐 팀 프로젝트 뿐만아니라 조별과제등 에 대해서 나는 좋은 경험을 가진적이 없다. (나중에 다른글을 통해서 이야기를 적을까 생각중이다.)
그래서 프로젝트 시작단계에서 기대보다는 걱정이 내 생각속 의 파이를 크게 차지 했다.

😉 발언이나 행동은 팀원에게 많은 영향을 준다.

( 프로젝트가 끝날때 쯤이야 발견한 박제된 과거의 나 😣)

내가 하는 행동,발언들이 팀에게 생각보다 많은 영향을 미쳣던 것 같다..

🔨 해보기 전까지 모든것을 알수는 없다.

🤔 처음도입해보는 기능과 기술들 그걸 도입하기까지 망설임이 많았던것같다.

Socket을 이용한 채팅구현, AWS 배포, CI-CD 등 처음 해보는것들을 도입하기전 되려 겁을먹고 잘할수있을까에 대해 생각하면서 망설임이 많았던 것 같다. 그럴때 마다 나는 " 그래요 해보죠 " 하며 담담하게 말했던것같다. 걱정만 하기보다는 일단 문제와 직접 부딪히는걸로!

🙄 누구의 일도 아니지만 '우리 일' 이 있다.

🐬 협업을 하다보면 ~의 담당으로 구분 지을수 없는부분이 생긴다. 가령 A와B 연동에서 생기는 이슈들에 대해서는 A 와 B 같이 고민해야할 문제라고 생각한다.

FE 파트와 BE 파트 연동시 FE 파트에서 "400에러가 나와요.", "500에러가 나와요."로 소통하였는데 기존 BE 파트 코드에서 요청이 올바른경우에만 정상적인 response를 해주었기 때문에 오류를 바로 파악하기 힘들었다. 그래서 원활한 소통을 위해 추가적으로 ApiResponse 공통 코드를 작성하여 반환하였다.

{	
  	"status": 400, // HttpStatus 응답값
  	"code": USER_NOT_FOUND, //응답코드에대한값 예제는 사용자를 찾을수없을경우
  	"msg":	"유저를 찾을수없습니다.", // 에러코드일경우 에러에 대한 메시지,성공일 경우 성공에대한 메세지
 	"data":[]  //데이터가 있을경우 내부에 담아서 반환
}

위와같은형태로 RestController 형태를 변경해주니 FE 분들도 백엔드에서 어떤문제가 발생한지 직관적으로 파악할수 있었고 BE파트에서도 예외코드를 추적하기에 편리하였다.

🙃 그럼에도 모든일이 항상 계획대로 되는것은 아니다.

😥 4주차에 FE팀원중 한분이 개인사정으로 하차하게 되었다.

FE파트 팀의 중심점이 되어 주신분이 갑작스럽게 나가게되어 FE팀원들이 정신적으로 많이 힘들어 했다. 하지만 떠난 사람 생각으로 우리가 해야할 일을 망강하면 안되었기에 FE 팀원들에게 남아있는 일정중 시작하지않은 기능은 드랍하고 지금 진행중인 작업에 대해서 완성도를 올리는것으로 방향을 다시 잡았다. BE 팀에서도 예상치 못한일에 놀랐지만 FE팀은 더욱 신경쓰이고 힘들었을것이라는 생각에 FE 업무 또한 신경 썻던것 같다. (일정 체크 , 진행 상황 확인등)

😅 프로젝트가 끝나고서야 보이는것들.

👀 프로젝트 중 에는 몰랐던것 들..

아쉬운점들

📁 불편한 프로젝트 디렉토리구조

😅 service ,controller 등 도메인 패키지로 따로 구분하지않고 한 service,controller 한 패키지 않에 여러도메인이 있으니 추후에 수정 하기위해 패키지 안에서 도메인을 추가적으로 찾는 작업이 필요했다.

# 프로젝트 폴더구조
├─common
│  └─exception
├─config
│  ├─chat
│  ├─redis
│  └─security
├─controller
├─dto
│  ├─apply
│  ..
├─entity
│  └─chat
├─repository
│  ├─impl
│  └─mongo
├─service
│  └─impl
├─type
└─util

패키지 명이 중복되는것이 싫어서 한 패키지에 모든 도메인을 넣은 결과 class 명으로 검색하거나 A개발에 필요한 코드뿐만아니라 C,D코드도 한패키지에 있으니 보기가 정말 불편했다. 😒 개선을 한다면 (도메인패키지) - service, 등으로 앞에 도메인이름으로된 패키지로 구분하여 새로운 패키지층을 만들어서 관리하는것이 더 좋았을텐데 .. 라는 아쉬움이 남는다.

😣 잘못만든 Rest api

팀프로젝트중 user의 상태, 이미지,정보등을 업데이트하는데 user 파트 담당따로 user 의 profile 을 내가 담당하게되었다. 그러면서 컨트롤러를 MyController 라고 작성했다.

@RequestMapping("api/my")
public class MyController{
	//...기타등등
}

이 컨트롤러를 통해서 profile을 업데이트하는데 "api/my/articles" , .. 등 my(나의) 등 모호한 단어로 작성된 api 를 만들었다. 기능적으로 이상하지 않았지만 멘토님으로부터 전적으로 프론트의 화면을 보며 설계한 api 피드백 받았다. 이 경우 내가아닌 다른사람이 유지보수를할때 곤란한점이 있을것같다.. (전혀 restful 하지않다..)

🐢 깊이있게 다루지 못한 기술들

팀프로젝트를 하면서 TDD 를 처음으로 도입해보았다. 그 과정에서 테스트를 할때 @SpringbootTest 어노테이션과 문제가 많았다. 테스트시 SpringContext (외부 주입변수 ,설정등 ) 의 통합적인 테스트를 진행하기가 어려웠다.
컨트롤러, 서비스 등 슬라이스 테스트를 작은단위로 테스트를 하며 진행했지만. 전체적인
여러 복합적인 테스트를 도전해보지 못한것이 아쉬웠다. (나는 정말 TDD를 실천한것일까🤔)