오늘 진행한 일

GitHub Repository 세팅

GitHub Projects

프로젝트의 작업들을 해야 할 작업, 진행중인 작업, 완료된 작업으로 구분해서 관리하는 것이 태스크 관리에 훨씬 도움이 된다는 생각이 들었다. 마침 GitHub에서는 GitHub Projects라는 프로젝트를 관리할 수 있는 기능을 제공하고 있다.

GitHub Projects는 칸반보드를 제공하며, 우리 프로젝트에서는 To Do, In Progress, Done 프리셋으로 이슈들을 관리하도록 했다.

앞으로 데모데이마다 2주 간의 기간을 하나의 Sprint로 잡고, 해당 기간에 발생하는 Issue는 해당 Sprint에 등록하기로 결정했다. Sprint에 등록되면 자동으로 To Do 탭으로 가며, 해당 Issue와 관련된 Pull Request가 생기면 해당 PR은 In Progress로 가게 되고, 이슈나 PR이 close 되게 되면 Done으로 이동한다.

Issues, Pull Requests Templates

프로젝트의 Issue와 Pull Request를 작성할 때 형식을 통일해서 작성하는 것이 좋겠다는 팀원들간의 합의가 있었다. GitHub에서는 마크다운을 이용해 이를 지원하기 때문에, 마크다운 파일을 작성했다. ISSUE_TEMPLATE.md 파일을 작성하면 Issue를 생성할 때 자동으로 작성한 템플릿이 나오게 되는데, 다음과 같이 작성했다.

# 목표

# 주의사항(Optional)

마찬가지로 Pull Request도 PULL_REQUEST_TEMPLATE.md 파일을 작성해서 템플릿을 생성할 수 있다.

# issue: 

# 작업 내용

Pull Request는 반드시 squash merge

코드리뷰가 완료된 Pull Request를 merge 할 때 방법은 merge commits, squash merging, rebase merging이 있는데, main 브랜치에 가장 깔끔하게 커밋 이력을 남길 수 있는 squash merging만 허용하고 나머지 merge 방법은 허용하지 않도록 정하고 GitHub에 설정해주었다.

페어 프로그래밍

백엔드 크루 5인이 함께 한 페어가 되어 페어 프로그래밍을 진행했다.

키보드 단일 조회 기능 구현

다음과 같이 키보드 단일 조회 기능을 구현했다.

• Keyboard 엔티티와 KeyboardRepository를 구현 완료
  • @DataJpaTest를 사용한 테스트
• 키보드를 id값으로 조회할 수 있는 기능만 포함하는 KeyboardService 구현 완료
  • 필요한 response dto 생성
  • Mockito를 활용한 Service Layer 테스트
• 키보드 단일 조회 기능을 api로 매핑
  • RestAssured를 활용한 인수 테스트
  • Controller Layer 테스트는 Documentation 작업으로 대체하기로 결정

오늘의 페어 프로그래밍에서 좋았던 점

5명이 의견을 내면 사공이 많아서 배가 산으로 갈 수도 있어 걱정을 했는데, 각자 근거를 가지고 의견을 내고 더 타당한 의견을 채택하는 식으로 진행을 하다 보니 큰 트러블 없이 진행할 수 있었다. 오히려 몇몇 크루가 놓치고 넘어가는 부분을 다른 크루가 잡아낼 수 있는 가능성이 높아지고, 실제로 아직 서로 익숙하지 않은 컨벤션 통일 과정에서 네비게이터 역할을 하는 크루들이 컨벤션을 짚어주면서 진행해서 컨벤션을 잘 맞출 수 있었다.

오늘의 페어 프로그래밍에서 아쉬웠던 점

굳이 아쉬웠던 점을 꼽자면 인원이 많은 만큼 드라이버를 다시 하기까지 돌아오는 텀이 길어서 약간 심심했다는 정도? 그리고 기능 하나를 구현하는데도 컨벤션 정리하고 컨펌받고 진행하면서 코드를 짜는데 시간이 오래 걸렸다는 정도가 있다. 이 부분은 차차 익숙해지면 나아지리라 생각한다.

오늘 발생한 이슈

해결한 이슈

• 키보드 생성 API를 만들지 않아 인수 테스트 시 테스트 용 데이터 추가가 곤란
  • 만족스럽지는 않지만 KeyboardRepository를 인수 테스트에서 @Autowired 해와서 사용하기로 결정
  • 관리자 계정을 만들어 키보드 생성 API를 열 일이 있으면 테스트 코드 리팩토링을 고려하기로 함
  • 추후 가독성을 위해 테스트 픽스처 클래스를 만드는 방법도 고려하기로 함
• 패키지 구조가 기능 별(도메인 별)로 되어 있는데, 곰곰히 생각해 본 결과 오히려 어울리지 않는 구조가 된다는 의견 제기
  • 다음 이슈에서 패키지 구조를 변경하기로 결정

해결되지 않은 이슈

• 이미지를 어떻게 확보하고 저장할 것인지
  • 이미지 확보에 대한 문제는 저작권 문제로 인해 조금 더 고려해보기로 결정
  • 이미지 저장은 코치님께 문의 결과 AWS S3 인스턴스를 한 개 사용할 수 있다고 하니 S3에 저장하는 것으로 결정
• keyboard 테이블에 어떤 컬럼을 추가해야 할 지
  • 목요일 회의를 통해 결정

내일 목표

내일은 레벨 인터뷰로 인해 프로젝트가 진행되지 않으므로 레벨 인터뷰에 집중하자.