[단축 URL 프로젝트 URLumberjack] - 기타 규칙 정의

0. 개요

서버 및 기술외에 프로젝트에 필요한 가이드라인이나 도구를 선택한 이유과 근거를 작성했습니다.

 

1. API 문서화 툴/프레임워크

 

RestDocs

Swagger를 문서화 툴이라고 하기에는 조금 애매하지만, API별로 테스트도 가능하면서 API에 대한 스펙을 출력해주기에 RestDocs와 비교를 해 보았습니다.

RestDocs를 선택한 이유는 다음과 같습니다.

1. 스웨거만 사용해 봤기에, 사용해보지 않은 RestDocs에 관심이 갔습니다.
2. 테스트코드를 작성하며 진행할 것이므로, 문서작성에 반드시 테스트코드가 필요한 RestDocs를 유지하는데 문제가 없을것이라 판단했습니다.
3. RestDocs는 문서화를 위해 많은 클래스를 유지관리 해야 합니다. 그러나, Swagger는 프로덕션 코드가 지저분해지고, 이를 방지하기 위해 @ApiModel을 활용해 추상화를 하게 되는데, 이는 결국 RestDocs처럼 별도의 클래스를 관리하게 됩니다.
   따라서, swagger라고 특별히 유지보수할 클래스 수가 적어지진 않습니다.

구글링을 해 보니, 스웨거와 Restdocs를 둘다 사용할 수 있는 방법이 있었습니다.

우선 RestDocs를 사용해 개발하고 이후 swagger와 같이 사용하도록 개발할 예정입니다.

2. Code convention

https://github.com/naver/hackday-conventions-java

Naver campus hackday java convention

대표적으로 google의 java convention과 naver의 java convention이 있었습니다.

그중 naver java convention을 선택했습니다.

선택한 이유는 다음과 같습니다.

1. 구글 컨변션과 큰 차이가 없어, 컨벤션을 준수해 작성하는데 의의가 있고 생각했습니다.
2. 한글문서여서 이해가 쉽습니다.
3. 예제코드가 항목마다 작성되어 있어 학습및 적용이 쉽습니다.

3. VCS Rule

git flow, github flow, gitlab flow등 버전관리를 위한 다양한 가이드라인이 존재했습니다.

그중 github flow를 소개하며, 선택한 이유도 서술해 보도록 하겠습니다.

특징 및 사용법

• master 브런치는 어떤 때든 배포가 가능합니다.
• 새로운 일을 시작하기 위해 master에서 브런치를 생성할 때, 어떤 작업을 하는지 이름에 드러나게 작성합니다.
• 원격 브런치로 본인의 작업물을 수시로 push를 할 수 있습니다.
• pull request는 병합을 진행하거나 피드백 및 도움이 필요할때 진행합니다.
• 작업물에 대해 컨펌이나 피드백이 완료되면 master에 병합합니다.
• master가 병합되거나 push를 받았다면 즉각 배포되어야 합니다.

 

선택 이유

1. 브런치 전략이 단순합니다.
   혼자 진행하는 프로젝트이므로, 복잡한 flow는 부담이라고 생각했습니다.
2. 코드 리뷰를 자연스럽게 사용할 수 있습니다.
   설정 및 문서작성을 제외하고 master브런치에 직접적인 push를 지양하게 되면,
   master 브런치에 pull request 요청을 통해서 코드리뷰를 받는데 전혀 문제가 없고 자연스럽습니다.
3. 수동배포시 매번 배포를 해야하는 번거로움이 있지만, 자동화 배포를 구현할 것이기에 문제가 없습니다.
4. 모바일 어플리케이션에 비해 웹은 릴리즈 개념이 비교적 희박하므로, 웹 개발엔 더 알맞다고 생각합니다.
   웹 어플리케이션은 모바일 어플리케이션에 비해 릴리즈 주기가 짧고 새로운 기능과 버그수정을 빠르게 배포하기 떄문입니다.