Spring Boot 협업(1)

처음으로 여태껏 배운 스택들을 활용하여 팀원들과 함께 프로젝트를 만들게 되었다.
확실히 프로젝트만 봤을 때 혼자서 한다고 생각하면 꽤나 걸릴 것 같아보였던 프로젝트였으나, 토의하고 역할분담을 하니 각자 도메인을 하나씩 맡게 되었다.

기초 설계

와이퍼 프레임

• 팀원들과 어떤 것을 만들지 공유 하기 위해 와이어 프레임을 설계했다.
• 우리는 백엔드 개발자 이기에 기본적인 뷰어를 그려보고 그 안에 어떤 데이터와 로직이 필요한지 설계하기 위해 다같이 그려보았다.

• 와이어프레임을 그려봄으로써, Entity는 무엇이 필요한지 각 API별 필요한 로직은 무엇인지 가늠 할 수 있게 되었다.

ERD 설계

• 각 API별 데이터 흐름과 로직 설계를 위해 가볍게 ERD 속성들과 연관관계를 이어주었다.

• 다만 팀 내 연관관계에 관련해 개념 이해가 어려우신 분들이 꽤나 계셨었는데, 관계를 이어주고 설명을 해주는 시간을 갖으니 팀원들도 이해하고 나 또한 개념을 다질 수 있는 좋은 경험이 되었다.

ERD 상세설명

• 간단하게 가시성이 좋은 ERD를 설계하였으니 내부적으로 남이 봤을 때 이해가 가능할 정도로 설명이 필요하다고 생각한다.

• 따라서 각 속성과 연관관계에 이은 속성이 무얼 의미하는지 설명까지 설계하였다.

위 사진 뿐만아니라 요청, 응답에 대한 코드와 POSTMAN의 입/출력 JSON 값 또한 설명해주었다. 그래야 프론트 엔드 입장에서 봤을 때 데이터를 어떻게 끌어다 오는지 알 수 있기 때문이라고 생각했다.

트러블 슈팅(1)

• 다만 팀원은 많고, 해야될 과업도 두루뭉실했기 때문에 다들 뭔가를 작성하거나, 요구사항에 대한 얘기를 할 때 적는 사람이 있고, 바라보는 사람이 있다는 것을 느꼈다. 따라서 역할 분담이라는 것이 중요하다는 것을 알 수 있었다. 각자 도메인이나 API에 대한 역할 분담이 되어있더라면, 할당된 업무에 관련해 책임지고 작성할 수 있게 될 것이고, 일의 효율은 오를 것이라고 생각하였다.

• 이 또한 튜터님에게 찾아뵈었을 때 듣게된 사실이기도하고 팀장님께서도 필요하다고 느끼셨기에 소통하고 역할 분담하여 무사히 작성할 수 있게 되었다.

• 팀장에 대한 역할이 다른 프로젝트를 했을 때와 달리 협업이라는 것이 들어갔을 때 굉장히 중요한 직책이라고 생각이 들었다.

API 명세서

• 이제 필요한 데이터 값들과 각 API별 필요 로직을 봤으니 실제 API를 구현함에 있어 설계를 먼저 진행해주면 되겠다.

• API명세서를 잘 짜게되면 무엇이 좋느냐, 오픈북이 될 수 있다.

• 코드를 짜기에 앞서 구상과 설계가 잘 끝나 있으면 주어진 말만 보고서 코드로 옮기기만 하면 되는 수준에 이르르기 된다.

• 귀찮더라도 세부적으로 쓰려고 노력했고, 코드 작성 간에 수정할 소요가 있다면 수정해야될 귀찮은 소요가 있지만 적응하고 습관화하려고 노력하였다.

• 다음과 같이 할당된 API에 담장자 이름을 써놓음으로써 조금 더 책임감을 느낄 수도 있고, 명확하게 어떤 API를 만들어야되는지 적혀 있기 때문에 코드 작성간에 고민할 거리는 없을 것이다.

튜터님 피드백

• API url 네이밍을 할 때 같은 기능은 최대한 묶는게 좋다는 것을 이해했다.

• 최초 게시물의 정렬과 필터가 많아 API가 꽤나 나올 것으로 판단하여 GET매핑을 통해 3~4가지정도의 조회 기능을 구현하려고 하였다.

• 하지만 같은 조회기능이면 RequestParam을 통해 한 가지의 API를 통해 여러개의 필터를 구현하는 게 맞지 않느냐 라는 피드백을 받았고, 가시성이 훨씬 났다고 판단했다.

• 다만 서비스에서 로직을 구현하는데 있어 꽤나 애를 먹었다..

• API의 url은 어떤 것으로부터 오는 것인지 육안으로 보기좋게 하라는 말을 들었던지라, 정확한 기준이나 맞는지 긴가민가했지만 피드백을 통해 확실히 이해하였고, 다만 현업에서는 그 현장에 맞는 컨벤션을 따르는 것이라고 생각하기로 하였다.

GIT 협업

• 프로젝트 생성

• 파일 구조화 통일

• 네이밍 및 커밋 컨벤션 통일

• Main Branch 생성

• Main으로부터 Dev브랜치 생성

• 각 팀원은 Dev브랜치로부터 새 브랜치 생성 후 작업 시작

• 작업이 끝나면 Dev브랜치로 PR 신청

• 코드리뷰 후 머지 진행

• 머지가 끝나면 팀원에게 알린 후 다른 팀원은 머지된 Dev v2를 Pull 받고 다시 작업 진행

• 반복 진행

• 어떤 작업을 하던 팀원과 함께 공유하는 것이 가장 중요하다는 것을 느꼈다.