Skip to content

Backend Wiki

Jump to bottom
Yun edited this page Jan 18, 2026 · 16 revisions

Devths Backend Wiki

서비스 바로가기 개발 후 추가 예정

Backend Repository


목차


개발 일정

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

컨벤션 룰

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 다이어그램: 👉 ERDCloud 링크
  • 핵심 전략: 정규화/반정규화 트레이드오프 고려, 인덱스 최적화

2단계: API 설계

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

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

3단계: 기술 검토 및 선정

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

4단계: 도메인 테크스펙

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

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)

트러블 슈팅


코드 품질 관리 도구

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

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

🚩 Devths Dashboard

🏠 Main

🛠 Engineering Tracks

📝 Knowledge Base

📂 Agile & Scrum Templates

Planning

Sprint Execution

Review & Retro

Clone this wiki locally