테이블 구조 재설계는 이제 작업을 시작하기 위한 틀을 마련한 것이고, 앞으로 생각해야 할 것이 많았다.
먼저 Git 전략이다.
우리는 데이터베이스 형상 관리를 위해 Flyway를 사용하고 있다.
이번 작업에서는 테이블 명을 완전히 바꿀 계획이었기 때문에, 기존처럼 각각 develop 브랜치에 PR을 따로 날리는 방식을 선택할 수 없었다. Flyway를 먼저 적용하는 순간 DB의 구조가 바뀌어서 기존 API들이 문제가 생길 것이고, API부터 바꾸는 순간 구버전 DB와 새롭게 만든 API가 호환되지 않을 위험이 있었다.
따라서 우리는 develop에서 분기한 브랜치에서 작업을 진행했다.
1. develop에서 브랜치를 하나 판 다음에
2. 같은 작업 환경을 만들기 위해 해당 start 브랜치에서 flyway 파일을 적용해서 각각 로컬mysql에 적용을 시켰다.
3. 그렇게 해서 각각 팀원들이 분기처리를 해서
4. 한명이 entity와 repo등의 최대한 겹치는 작업을 진행했다.
5. 다른 인원들이 각각 4번을 pull하고
6. 각각 작업 한 후 commit, 각각 merge후 다음 인원들이 pull하고 다시 merge하고를 반복했다.
하지만 이 방법이 최선이라고는 할 수 없었다. 각 팀원이 최소 3개의 API를 만들어서 나중에 개별 브랜치에 머지하면서 충돌이 빈번하게 발생했기 때문이다.
충돌을 최소화하려고 노력했지만, 예상대로 충돌이 계속 발생했다. 현업에서는 CRUD를 나눠서 작업하기보다는 각자 모듈을 하나씩 맡아서 작업한다고 한다. 우리도 작업할 때 보통 모듈을 하나씩 맡아서 하는데, 이번에는 단기간에 작업을 완료해야 했기 때문에 CRUD를 각각 복잡하게 나눠서 진행했다. 이를 통해 페어 프로그래밍의 중요성을 많이 느꼈다.
실제로 마지막 날 최종 PR을 날릴 때는 드라이버와 네비게이터를 나눠서 작업했다. 이 방식이 기존 방식보다 훨씬 효율적이었다.
이제는 깃 전략을 세웠으니 어떻게 작업했는지를 보자(3편에서 계속..)
