You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CLAUDE.md
+5-24Lines changed: 5 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,22 +11,11 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
11
11
- Suggest based on logical reasons.
12
12
- For every request, follow this order before writing any code:
13
13
1. Analyze the process (현재 구조/흐름 파악)
14
-
2. Suggest a direction (어떤 방향으로 접근할지 제시)
15
-
3. Present trade-offs (각 방향의 장단점 제시)
16
-
4. Do NOT write code unless the user explicitly asks with a direct command such as "개발해줘", "작성해줘", "구현해줘".
17
-
18
-
## Commenting Convention
19
-
20
-
- Comments should be written in a single line whenever possible.
21
-
- Each comment must include the author's name and the date.
22
-
- Use IntelliJ's default `FIX ME` comment format.
23
-
- Use this for parts of the code where there may be a potential issue but immediate exception handling is unnecessary.
24
-
- Also use this for parts that are not yet finalized due to unclear business requirements.
25
-
26
-
## Test Code Convention
27
-
28
-
- Test method names must be written in **English**.
29
-
- But if the codes is related to test, write the comment for "given, when, then".
14
+
2. If anything is unclear or requires a decision only the user can make, ask clarifying questions before proposing a direction
15
+
3. Suggest a direction based on the analysis (and any answers received)
16
+
4. Present trade-offs for each direction
17
+
5. Do NOT write code unless the user explicitly asks with a direct command such as "개발해줘", "작성해줘", "구현해줘".
18
+
- When implementing from a GitHub issue with multiple feature items, process one item at a time: complete the full analyze → clarify → direction → trade-off → explicit approval cycle for a single item before moving to the next.
**복잡한 쿼리**: `*RepositoryCustom` 인터페이스 + `*RepositoryImpl`(QueryDSL) 패턴을 사용한다.
88
-
89
-
**DB 마이그레이션**: Flyway를 사용하며, `src/main/resources/db/migration/V{n}__{설명}.sql` 형식으로 관리한다. `ddl-auto: none`이므로 스키마 변경 시 반드시 마이그레이션 파일을 추가해야 한다.
90
-
91
76
### API 버전 관리
92
77
93
78
일부 Controller/Service는 V1/V2로 버전이 분리되어 있다(예: `ReviewController`/`ReviewControllerV2`, `ReviewService`/`ReviewServiceV2`). 새 기능은 V2 이상에 추가하거나, 필요 시 새 버전을 생성한다.
94
79
95
-
### 테스트
96
-
97
-
테스트는 `@SpringBootTest`로 실제 DB에 연결하여 실행한다. 목(Mock) DB를 사용하지 않는다.
98
-
99
80
### 배포
100
81
101
82
GitHub Actions(`deploy.yml`)로 Docker 이미지를 빌드하여 EC2에 SSH 배포한다. `prod`/`dev` 브랜치에 따라 배포 환경이 분기된다.
0 commit comments