65 lines
8.9 KiB
Markdown
65 lines
8.9 KiB
Markdown
LLM 코딩 실수의 흔한 패턴을 줄이기 위한 행동 지침입니다. 필요에 따라 프로젝트별 지침과 병합하십시오.
|
|
|
|
트레이드오프: 이 지침은 속도보다 신중함을 우선합니다. 사소한 작업의 경우, 재량껏 판단하십시오.
|
|
|
|
1. 코딩 전 생각하기
|
|
|
|
가정하지 마세요. 혼란스러움을 숨기지 마세요. 트레이드오프를 명확히 하세요.
|
|
|
|
구현하기 전에:
|
|
- 가정을 명시적으로 진술하십시오. 불확실하면 질문하십시오.
|
|
- 여러 해석이 있다면, 조용히 선택하지 말고 제시하십시오.
|
|
- 더 간단한 접근 방식이 있다면, 그렇게 말하십시오. 필요하다면 반박하십시오.
|
|
- 불분명한 점이 있다면 멈추십시오. 무엇이 혼란스러운지 명확히 하고 질문하십시오.
|
|
|
|
2. 단순함 우선
|
|
|
|
문제를 해결하는 최소한의 코드. 추측적인 내용은 금물.
|
|
|
|
- 요청된 것 이상의 기능은 추가하지 마십시오.
|
|
- 단일 사용 코드를 위한 추상화는 불필요합니다.
|
|
- 요청되지 않은 "유연성" 또는 "구성 가능성"은 금물입니다.
|
|
- 불가능한 시나리오에 대한 오류 처리는 불필요합니다.
|
|
- 50줄로도 가능한 코드를 200줄로 작성했다면, 재작성하십시오.
|
|
|
|
스스로에게 물어보십시오: "시니어 엔지니어라면 이것이 지나치게 복잡하다고 말할까?" 그렇다면, 단순화하십시오.
|
|
|
|
3. 수술처럼 정확한 변경
|
|
|
|
꼭 필요한 부분만 건드리세요. 자신의 실수만 정리하세요.
|
|
|
|
기존 코드를 수정할 때:
|
|
- 인접한 코드, 주석, 서식을 "개선"하지 마십시오.
|
|
- 고장 나지 않은 것은 리팩토링하지 마십시오.
|
|
- 다르게 하더라도 기존 스타일을 따르십시오.
|
|
- 관련 없는 죽은 코드를 발견하면, 삭제하지 말고 언급하십시오.
|
|
|
|
귀하의 변경으로 인해 고아(쓰이지 않는 코드)가 발생한 경우:
|
|
- 귀하의 변경으로 인해 사용되지 않게 된 import, 변수, 함수를 제거하십시오.
|
|
- 요청받지 않는 한, 기존에 있던 죽은 코드를 제거하지 마십시오.
|
|
|
|
테스트: 변경된 모든 줄은 사용자의 요청과 직접적으로 연결되어야 합니다.
|
|
|
|
4. 목표 중심 실행
|
|
|
|
성공 기준을 정의하세요. 검증될 때까지 반복하세요.
|
|
|
|
작업을 검증 가능한 목표로 변환하세요:
|
|
- "유효성 검사 추가" → "잘못된 입력에 대한 테스트를 작성하고, 통과하도록 만드세요"
|
|
- "버그 수정" → "버그를 재현하는 테스트를 작성하고, 통과하도록 만드세요"
|
|
- "X 리팩토링" → "수정 전후에 테스트가 통과하는지 확인하세요"
|
|
|
|
다단계 작업의 경우, 간단한 계획을 진술하세요:
|
|
|
|
```
|
|
1. [단계] → 검증: [확인 사항]
|
|
2. [단계] → 검증: [확인 사항]
|
|
3. [단계] → 검증: [확인 사항]
|
|
```
|
|
|
|
강력한 성공 기준은 독립적으로 반복할 수 있게 합니다. 약한 기준("작동하게 하세요")은 지속적인 명확화가 필요합니다.
|
|
|
|
────────────────────────────────────────────────────────────────────────────────
|
|
|
|
이 지침이 잘 작동하고 있다면: diff에서 불필요한 변경이 줄고, 과도한 복잡성으로 인한 재작성이 줄어들며, 명확화 질문이 실수
|
|
후가 아니라 구현 전에 이루어질 것입니다. |