[중고거래사이트 - 2] 테이블 재구성 및 Git-Flow 모델로 구현

테이블 재구성

사용자 정보를 담는 테이블 설계를 잘못했다. PK로 int값을 저장하도록 했는데, 생각해보니 아이디가 충분히 고윳값이 될 수 있다. 왜 처음부터 아이디를 PK로 사용할 생각을 하지 못했을까? 테스트 클래스 작성 시 이상한 부분을 발견해서 기존 테이블을 삭제하고 다시 생성했다. 테이블이 몇 개 없는 데다 여러 제약조건이 얽혀있어서 처음부터 작업하는 것이 더 빠르겠다고 판단했다. 

 

또한 채팅 관련 로직을 처리할 세 개의 테이블을 추가로 생성했다. 이 문제는 유스케이스를 수정하면서 발견했다. 처음부터 체계적으로 기능 정리를 했더라면 반복된 작업에 의한 시간 낭비가 없었을 것이다. 반성하고 다음부터는 이런 일이 없도록 하자. 고칠 수 있는 것은 확실히 고치자.

 

Git-Flow 모델

Git-Flow 모델은 개발자 Vincent Driessen에 의해 소개된 깃 브랜치 관리 모델이다. 

origin 명령어로 생성되는 master 브랜치를 최종적으로 배포되는 브랜치로 하고 개발 작업을 develop, feature 브랜치를 통해 수행한다. 아래 그림에서 설명하듯이 서비스 기능별로 feature 단위로 분류해서 개발하고 개발이 완료된 feature 브랜치는 develop 브랜치와 merge 한다.

 

이 모델을 통한 브랜치 관리는 처음이다. 사실 브랜치 관리라는 것을 처음 해본다. 아, 국비교육 조별과제 때 했었구나. 사실 조별과제 당시 조장이 브랜치 관리를 전담했고, 조원이었던 본인은 구현에만 집중했었다. 그런데 이번에는 내가 보스이기 때문에 직접 해야 한다. 진정한 의미의 브랜치 관리는 이번이 처음인 셈이다. 처음에는 브랜치 관리라는 것을 해야겠다는 생각조차 하지 않고 그냥 master 브랜치 하나를 가지고 꾸역꾸역 개발해야겠다고 생각했다. 그런데 GitHub에서 다른 사람들이 했던 프로젝트(Fork, Star가 많은 것을 중심으로)를 살펴보니 브랜치 관리를 하고 있었다. 또한 Issues, Wiki 탭도 사용 가능하다는 사실을 처음 알았다. 그때 생각했다. '아직 멀었구나..' 그리고 동시에 기뻤다. 이제 이전보다 더 나은 사람이 될 수 있으니까.

 

Git-Flow 모델에서 제안하는 방법대로 기능을 feature 브랜치로 분리했다. 구글링을 해보니 리포지토리의 Issues 탭에서 구현할 기능을 명시하고 명시된 이슈 번호(#번호)를 통해 feature 브랜치를 구분하는 것을 추천했다. 오, 그런 방법이 있었다니. 또한 구현 후 commit 작업을 할 때 '#번호'를 커밋 메시지에 적으면 자동으로 리포지토리에 명시된 이슈 번호와 연결된다. 이렇게 편리할 수가. 말 그대로 잘 모르면 몸이 고생한다.

 

Git-Flow 모델에 대한 자세한 설명 및 사용법은 아래 참고 링크에서 확인 가능하다.

 

 

 

인터페이스의 접근제어자는 무조건 public

이다. 인터페이스는 기능 구현이 없는, 기능에 대한 간단한 명시만 해놓은 메소드를 담고 있는 클래스이기 때문에 세부 기능 구현(implements)을 위해 접근이 용이하도록 기본 접근제어자를 public으로 한다. 그렇기 때문에 접근제어자를 생략하더라도 자동으로 public으로 인지한다.

 

참고

https://nvie.com/posts/a-successful-git-branching-model/

A successful Git branching model

https://devport.tistory.com/12

[개발] Github 이슈와 커밋 메시지를 연결해보자

https://limkydev.tistory.com/222

[JAVA] 클래스와 인터페이스의 접근제어자