<aside> 🙍‍♂️

[MVP 기능 명세] 도메인 전반적인 설명

[Github Issue ] 도메인 별 기능 및 구현에 대한 논의

[API 명세] 특정 url에 메소드에 대한 논의 (+url 규칙, 권한처리, 토큰 전달방식 등)

</aside>

<aside> 📌

on-going 컨벤션

[프론트엔드]

• 테스트가 필요하다면 임시로 만들어 올린 후 이슈,PR 에서 상세설명 (안쓸 파일은 제거)

[백엔드]

• test 성공처리(문서화) , test 예외 처리 부분은 메서드만 만들어놓기

[github]

• 개발시에는 화면,서버 모두 한 이슈에서 관리 (서버에서만 리펙토링하는 경우엔 서버 라벨 붙이기)
• 새로운 기능 구현시 main 에서 branch 생성하여 작업
• commit 은 해당 기능에만 집중하여 커플링 없애기
• 작업 중 스켈레톤, css 스타일링 등 공통사항에 대한 작업은 이슈이름에 [공통] 을 달아서 main 브렌치에 그때그때 직접 푸시하기 (특정 기능 브렌치 작업중 main pull해서 최신화 하며 개발)
• 어떤 기능을 만드는데 공동작업해야한다면 해당 branch를 공유해 쓰고 PR통해 리포트
• PR 제목은 내용을 요약하여 담되 단순 머지인 경우 Merge A to B
• Merge 는 상대가 해주기 (단, 급한 건은 머지하고 슬랙에 공유)
• Fork 후 개발시에는 개발중인 서브브렌치에서 upstream 메인 브렌치에 바로 PR과 함께 push 요청

[slack]

• PR이 push 되면 발생하는 슬랙 알림에 간단히 요약남기기
• 문제 발생시 hotfix 에 관련사항 남기고 해결시 댓글로 남겨 관리하기 </aside>

코딩 컨벤션

• 블록 들여쓰기는 4 space << tab
• 열 제한 120자 이내
• 들여쓰기를 지속하려면 다음 줄에 8 space << tab
• 가독성 향상을 위해서는 어디서든 enter
• 3항 연산자를 쓰지 않는다.
• 함수(또는 메서드)의 길이가 15라인을 넘어가지 않도록 구현한다.
• indent(인덴트, 들여쓰기)는 2까지만 허용한다.(메소드를 적극적으로 분리하여 구현할 것)
• 상수값은 Java Enum을 사용하여 프로그램을 구현한다.
• 구현한 기능에 대한 단위 테스트를 작성한다. 단, UI 로직은 제외한다.

주석 규칙

• 직관적인 클래스, 함수, 변수명을 쓰되 주석을 적극적으로 달아 코드를 문서화
• 구현 혹은 리팩토링 예정인 것은 TODO 를 사용하기

클래스 명명 규칙