Devths Backend Wiki

개발 일정

기간	주요 작업
25/12/22 ~ 26/1/4	서비스 기획, 기술 검토
26/1/5 ~ 1/18	설계 (ERD, API, 테크스펙)
1/19 ~ 2/1	MVP 개발
2/2 ~ 2/8	1차 배포 및 출시

컨벤션 룰

1. 코드 스타일 가이드

예시

EditorConfig 설정

설정 항목	값	설명
charset	utf-8	인코딩 통일
end_of_line	lf	Mac/Windows 줄바꿈 차이 해결
indent_style	space	탭 대신 스페이스 사용
insert_final_newline	true	파일 끝에 개행 추가
trim_trailing_whitespace	true	후행 공백 제거
max_line_length	120	가독성을 위한 라인 길이 제한

2. CheckStyle 설정

예시

항목	규칙
클래스명	`PascalCase`
변수명 및 메서드명	`camelCase`
상수명	`UPPER_SNAKE_CASE`
패키지명	`lowercase` (com.devths.domain)
탭 사용	사용 안함 (Space 4)
줄 바꿈	LF
최대 라인 길이	120
제어문 블록 {}	K&R Style (같은 줄에 시작)
연산자 배치	줄바꿈 시 연산자로 시작
import 순서	`java` -> `javax` -> `org` -> `com`
주석 스타일	Javadoc 형식 준수

3. 커밋 메시지 컨벤션

예시

** 커밋 메시지는 type: message 형식을 따르며, 아래의 규칙을 따릅니다. **

제목 규칙

제목은 다음 대소문자 스타일 중 하나를 따라야 합니다: - sentence-case - start-case - pascal-case - upper-case - lower-case
제목 끝에 마침표(.)를 사용하지 않습니다.
제목은 최소 5자 이상이어야 합니다.
전체 헤더는 72자를 초과하지 않아야 합니다.

타입	설명
build	빌드 시스템 또는 외부 의존성 변경
chore	패키지 매니저 설정 등 소스 코드 외적인 변경
content	콘텐츠 변경
docs	문서 수정 (README, Wiki 등)
feat	새로운 기능 추가
fix	버그 수정
refactor	코드 리팩토링 (기능 변경 없음)
style	코드 포맷팅, 세미콜론 누락 등 (로직 변경 없음)
test	테스트 코드 추가/수정
deploy	배포 관련 변경

커밋 메시지 형식

type: 제목 (#이슈번호)

본문 (선택 사항)

예시

feat: 회원가입 기능 구현 (#12)

- Spring Security 설정 추가
- User 엔티티 생성 및 Repository 구현

4. 추가 규칙

예시

PR 제목은 커밋 메시지와 동일한 형식을 유지합니다.
한 번의 PR은 하나의 목적을 가져야 합니다.
코드 리뷰를 거친 후 병합을 수행합니다.

이 컨벤션을 준수하여 팀의 코드 품질을 유지하고 원활한 협업을 진행합시다!

시스템 설계 (System Design)

각 설계 단계의 상세 내용은 링크된 서브 페이지에서 확인할 수 있습니다.

1단계: ERD 설계

Why: 데이터 무결성을 보장하고, 향후 비즈니스 확장에 유연하게 대응하기 위한 데이터 모델링입니다.

👉 [상세] ERD 설계 및 테이블 정의서 링크

ERD 다이어그램: 👉 ERDCloud 링크
핵심 전략: 정규화/반정규화 트레이드오프 고려, 인덱스 최적화

2단계: API 설계

Why: 클라이언트와의 명확한 인터페이스 약속이며, 리소스 중심의 설계를 통해 직관적인 사용성을 제공합니다.

👉 [상세] API 명세서 보러가기

👉 API 설계 과정에서의 고민 정리 문서

URI 규칙: RESTful 원칙 준수 (자원=명사, 행위=메서드)
주요 내용: 인증 시퀀스, 공통 응답 규격(JSON), 에러 코드

3단계: 기술 검토 및 선정

Why: "남들이 써서"가 아닌, **"우리 서비스의 규모와 특성에 적합한 기술"**을 비교 분석하여 선정합니다.

👉 [상세] 기술 스택 검토 및 선정 문서 보러가기

4단계: 도메인 테크스펙

Why: 복잡한 비즈니스 로직을 코드로 짜기 전에 시각화하여 논리적 오류를 사전에 방지합니다.

👉 [상세] 공통 도메인 테크 스펙

👉 [상세] 유저 도메인 테크 스펙

👉 [상세] 채팅 도메인 테크 스펙

👉 [상세] AI 챗봇 도메인 테크 스펙

5단계: 인증/인가 설계

👉 [상세] 인증/인가 설계

배포 환경 및 CI/CD 파이프라인

Why: 반복적인 수동 배포로 인한 휴먼 에러를 제거하고, 코드 변경 사항을 즉시 운영 환경에 반영합니다.

👉 [상세] 클라우드 인프라 설계서 보러가기

[Image of CI CD pipeline diagram]

1. 인프라 아키텍처

Cloud: AWS (EC2, RDS, S3)
Network: VPC (Public/Private Subnet 분리)

2. 파이프라인 구성

CI: Github Actions (Build -> Unit Test -> Lint Check)
CD: Docker Hub Image Push -> EC2 Pull & Run (Blue/Green Deployment)

트러블 슈팅

1. 트러블 슈팅 제목

코드 품질 관리 도구

지속 가능한 소프트웨어를 위해 부채를 관리하고 코드의 신뢰성을 정량적으로 측정합니다.

도구	역할	목적
.editorconfig	코드 포맷 통일	IDE 간 설정 차이로 인한 불필요한 코드 변경 방지
Checkstyle	코딩 컨벤션 검사	코드 스타일 일관성 유지 및 가독성 향상
JaCoCo	테스트 커버리지 측정	테스트되지 않은 비즈니스 로직 식별 (목표: 70%)
Java Test Fixtures	테스트 데이터 관리	테스트 코드 중복 제거 및 유지보수 용이성 확보
SonarQube	정적 코드 분석	코드 스멜, 보안 취약점, 버그 사전 탐지

Backend Wiki - 100-hours-a-week/9-team-Devths-WIKI GitHub Wiki

Devths Backend Wiki

목차

개발 일정

컨벤션 룰

1. 코드 스타일 가이드

2. CheckStyle 설정

3. 커밋 메시지 컨벤션

커밋 메시지 형식

4. 추가 규칙

시스템 설계 (System Design)

1단계: ERD 설계

2단계: API 설계

3단계: 기술 검토 및 선정

4단계: 도메인 테크스펙

5단계: 인증/인가 설계

배포 환경 및 CI/CD 파이프라인

1. 인프라 아키텍처

2. 파이프라인 구성

트러블 슈팅

코드 품질 관리 도구

⚠️ GitHub.com Fallback ⚠️

Backend Wiki - 100-hours-a-week/9-team-Devths-WIKI GitHub Wiki

Devths Backend Wiki

목차

개발 일정

컨벤션 룰

1. 코드 스타일 가이드

2. CheckStyle 설정

3. 커밋 메시지 컨벤션

커밋 메시지 형식

4. 추가 규칙

시스템 설계 (System Design)

1단계: ERD 설계

2단계: API 설계

3단계: 기술 검토 및 선정

4단계: 도메인 테크스펙

5단계: 인증/인가 설계

배포 환경 및 CI/CD 파이프라인

1. 인프라 아키텍처

2. 파이프라인 구성

트러블 슈팅

코드 품질 관리 도구

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️