프로젝트의 작업들을 해야 할 작업, 진행중인 작업, 완료된 작업으로 구분해서 관리하는 것이 태스크 관리에 훨씬 도움이 된다는 생각이 들었다. 마침 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
으로 이동한다.
프로젝트의 Issue와 Pull Request를 작성할 때 형식을 통일해서 작성하는 것이 좋겠다는 팀원들간의 합의가 있었다. GitHub에서는 마크다운을 이용해 이를 지원하기 때문에, 마크다운 파일을 작성했다. ISSUE_TEMPLATE.md
파일을 작성하면 Issue를 생성할 때 자동으로 작성한 템플릿이 나오게 되는데, 다음과 같이 작성했다.
# 목표
# 주의사항(Optional)
마찬가지로 Pull Request도 PULL_REQUEST_TEMPLATE.md
파일을 작성해서 템플릿을 생성할 수 있다.
# issue:
# 작업 내용
코드리뷰가 완료된 Pull Request를 merge 할 때 방법은 merge commits
, squash merging
, rebase merging
이 있는데, main
브랜치에 가장 깔끔하게 커밋 이력을 남길 수 있는 squash merging
만 허용하고 나머지 merge 방법은 허용하지 않도록 정하고 GitHub에 설정해주었다.
백엔드 크루 5인이 함께 한 페어가 되어 페어 프로그래밍을 진행했다.
다음과 같이 키보드 단일 조회 기능을 구현했다.
Keyboard
엔티티와 KeyboardRepository
를 구현 완료@DataJpaTest
를 사용한 테스트KeyboardService
구현 완료Mockito
를 활용한 Service Layer 테스트RestAssured
를 활용한 인수 테스트5명이 의견을 내면 사공이 많아서 배가 산으로 갈 수도 있어 걱정을 했는데, 각자 근거를 가지고 의견을 내고 더 타당한 의견을 채택하는 식으로 진행을 하다 보니 큰 트러블 없이 진행할 수 있었다. 오히려 몇몇 크루가 놓치고 넘어가는 부분을 다른 크루가 잡아낼 수 있는 가능성이 높아지고, 실제로 아직 서로 익숙하지 않은 컨벤션 통일 과정에서 네비게이터 역할을 하는 크루들이 컨벤션을 짚어주면서 진행해서 컨벤션을 잘 맞출 수 있었다.
굳이 아쉬웠던 점을 꼽자면 인원이 많은 만큼 드라이버를 다시 하기까지 돌아오는 텀이 길어서 약간 심심했다는 정도? 그리고 기능 하나를 구현하는데도 컨벤션 정리하고 컨펌받고 진행하면서 코드를 짜는데 시간이 오래 걸렸다는 정도가 있다. 이 부분은 차차 익숙해지면 나아지리라 생각한다.
KeyboardRepository
를 인수 테스트에서 @Autowired
해와서 사용하기로 결정keyboard
테이블에 어떤 컬럼을 추가해야 할 지내일은 레벨 인터뷰로 인해 프로젝트가 진행되지 않으므로 레벨 인터뷰에 집중하자.
👍👍👍
호시탐탐 염탐하며 배우겠습니다 으흐흐