-
Notifications
You must be signed in to change notification settings - Fork 1
Home
Yoo117 edited this page Oct 14, 2024
·
13 revisions
Local 실행 방법 자세히 보기
1. DB설치(docker 실행)docker compose up -d- 환경 변수 파일 추가 (.env 파일)
# SECRET_KEY
SECRET_KEY='django-insecure-da0mi_044pv-vs7-gpw8qb6t8=2czy@^er34_1^d'
# DEBUG
DEBUG=True
# DATABASE
DATABASE_ENGINE='django.db.backends.postgresql'
DATABASE_NAME='postgres'
DATABASE_USER='postgres'
DATABASE_PASSWORD='postgres'
DATABASE_HOST='localhost'
DATABASE_PORT='5432'
# ALLOWED_HOSTS
ALLOWED_HOSTS='*'
# KAKAOPAY
BASE_URL='https://www.weaverse.site/'
KAKAOPAY_CID='TC0ONETIME'
KAKAOPAY_SECRET_KEY='DEV797B9F2F7A1E7E41DE550A69B443143590619'
-
pyenv설치 및 활성화
# 가상환경 설치
python3 -m venv .venv
# 활성화
# 윈도우즈
.venv\Scripts\activate
# mac & linux
source .venv/bin/activate또는
# 가상환경 설치
python -m venv venv
# 활성화
source venv/bin/activate- 필요한 패키지 설치
pip install -r requirements.txt
- DB 마이그레이션
python manage.py migrate- 서버 실행
python manage.py runserver- 주요 용도: 실시간 채팅, 음성 통화, 파일 공유
- 사용 가이드라인:
- 중요한 결정사항은 항상 채팅으로 기록
- 음성 채널 사용 시 간단한 회의록 작성
- 주요 용도: 가상 공간에서의 팀 미팅 및 비공식 소통
- 사용 시나리오:
- 팀 미팅
- 페어 프로그래밍 세션
- 가상 사무실 공간으로 활용
- 주요 용도: 코드 작성 및 편집
- GitHub 계정을 통한 설정 동기화 권장
- 주요 용도: 버전 관리, 코드 협업, 이슈 트래킹을 위한 중앙 집중식 플랫폼
- 선택 이유:
- 풍부한 생태계와 다양한 라이브러리 지원
- 빠른 개발 속도와 생산성
- ORM의 강력함과 관리자 인터페이스 제공
- Tradeoff:
- 장점: 보안 기능 내장, 확장성
- 단점: 상대적으로 무거운 프레임워크, 학습 곡선이 있음
- 선택 이유:
- 복잡한 쿼리와 트랜잭션 처리에 강함
- JSON 필드 지원으로 유연한 데이터 모델링 가능
- 확장성과 대규모 데이터 처리 능력
- Tradeoff:
- 장점: 데이터 무결성, ACID 준수
- 단점: 초기 설정의 복잡성, MySQL에 비해 약간의 성능 차이
- 선택 이유:
- 자동화된 API 문서 생성
- 대화형 API 테스트 인터페이스 제공
- Django REST Framework와의 높은 호환성
- Tradeoff:
- 장점: 문서 유지보수 용이, 클라이언트 개발자와의 협업 개선
- 단점: 설정의 복잡성, 추가적인 의존성 발생
- 선택 이유:
- 상태를 저장하지 않는(stateless) 인증 방식으로 확장성 좋음
- 세션 관리의 복잡성 감소
- Tradeoff:
- 장점: 서버 부하 감소, 다중 서버 환경에서 유리
- 단점: 토큰 관리의 책임이 클라이언트에 있음, 토큰 탈취 시 보안 위험
- 선택 이유:
- pytest: 간결한 문법, 풍부한 플러그인 생태계
- Factory Boy: 테스트 데이터 생성 자동화
- Coverage.py: 코드 커버리지 측정으로 테스트 품질 향상
- Tradeoff:
- 장점: 테스트 작성 및 유지보수 용이, 높은 코드 신뢰성
- 단점: 초기 설정 시간 소요, 학습 곡선 존재
- 선택 이유:
- Docker: 일관된 개발 및 운영 환경 제공
- Gunicorn: 안정적인 WSGI 서버
- Nginx: 고성능 웹 서버 및 리버스 프록시
- Tradeoff:
- 장점: 확장성, 환경 일관성, 로드 밸런싱
- 단점: 설정의 복잡성, 리소스 오버헤드
- 선택 이유:
- GitHub 저장소와의 통합 용이성
- 다양한 워크플로우 템플릿 제공
- 무료 사용량이 넉넉함
- Tradeoff:
- 장점: 쉬운 설정, GitHub 생태계와의 통합
- 단점: GitHub에 종속, 복잡한 파이프라인의 경우 제한적일 수 있음
- 선택 이유:
- Black: 일관된 코드 스타일 강제
- isort: import 문 자동 정렬
- Mypy: 정적 타입 검사로 버그 조기 발견
- Tradeoff:
- 장점: 코드 가독성 향상, 버그 감소, 일관성 유지
- 단점: 엄격한 규칙으로 인한 초기 적응 기간 필요
- 선택 이유:
- python-dotenv: 환경 변수 관리 용이
- venv: 프로젝트별 독립적인 환경 구성
- requirements.txt: 의존성 관리 표준화
- Tradeoff:
- 장점: 환경 설정의 일관성, 재현 가능성
- 단점: 추가적인 설정 단계 필요, 의존성 관리의 수동성
서드 파티 라이브러리 자세히 보기
- 사용 이유: Cross-Origin Resource Sharing (CORS) 설정 간소화
- 장점: 프론트엔드와 백엔드 간 통신 보안 강화
- 사용 이유: 다양한 스토리지 백엔드 (예: AWS S3) 지원
- 장점: 파일 저장 및 관리의 유연성 제공
- 사용 이유: OpenAPI (Swagger) 문서 자동 생성
- 장점: API 문서화 프로세스 자동화, 클라이언트 개발자와의 협업 개선
- 사용 이유: 효율적이고 강력한 테스팅 프레임워크
- 장점: 간결한 문법, 풍부한 플러그인 생태계
- 사용 이유: 환경 변수 관리 간소화
- 장점: 보안 강화, 설정의 유연성
- 사용 이유: 이미지 처리 라이브러리
- 장점: 다양한 이미지 포맷 지원, 이미지 조작 기능
- 사용 이유: PostgreSQL 데이터베이스 어댑터
- 장점: 고성능, 스레드 안전성
- 사용 이유: HTTP 요청을 위한 간단하고 효율적인 라이브러리
- 장점: 직관적인 API, 다양한 HTTP 메서드 지원
- 사용 이유: 정적 타입 검사 도구
- 장점: 타입 관련 버그 조기 발견, 코드 품질 향상
- 사용 이유: 비디오 인코딩 및 처리 기능 제공
- 장점: 다양한 비디오 포맷 지원, 비디오 스트리밍 용이성
| 시간 | 내용 |
|---|---|
| 오전 | |
| 09:00-09:30 | 주말 팀원 개별 작업 공유 (진전, 에러 등) |
| 09:30-10:00 | (팀장 1차 미팅) 팀원 소통 및 개별 활동 |
| 10:00-10:30 | 팀장 미팅 내용 공유 (타팀 feedback도 함께) |
| 10:30-12:00 | 담당 앱 개발 진행(1) |
| 12:00-12:50 | 개별 작업에서 생기는 질문 및 고민 공유 |
| 오후 | |
| 14:00-14:30 | PR 리뷰 진행(PR 작성: 14:00 전) |
| 14:30-17:00 | 담당 앱 개발 진행(2) |
| 17:00-17:30 | 금일 정리 • 개별 작업에서 생기는 질문 및 고민 공유 • 팀원 개별 작업 확인 및 공유 • 전체 프로세스 위치 점검 • 구글 시트 업데이트 |
| 17:30-18:00 | (팀장 2차 미팅) 일일 및 주간회고 작성 및 확인 |
| 저녁 | |
| 18:00 이후 | 야간 작업 (자율) |
- 모든 팀원
- 기능 구현 트랙
- 토의 안건
- 주간 회고
- 유정(팀장)
- TODO
- Ground Rule
- Convention
- 홍광
- WBS
- 팀회의록
- 원길
- 연우
- Wiki 작성
- 오전 회의 및 discussion 활용
- 틈틈히 코드 코멘트 남기기(class와 def, 중요한 내용 추가)
- 오전 회의에서 담담자 설명 후 팀원 질문 답변 공유
- 담당자는 코멘트에 답변 준비
- 피어는 코드 스터디 및 질문 준비
-
개인 브랜치에 코드 푸시
- 대상: 조직 레포지토리의 개인 브랜치
- 테스트용으로 추가한 임시 코드는 푸시하지 않습니다.
- 단위 테스트 및 통합 테스트 코드는 푸시해야 합니다.
-
개발 브랜치로 풀 리퀘스트(PR)
- 대상: 조직 레포지토리의 개발 브랜치 (dev)
- 프로세스: 개인 브랜치에서 dev 브랜치로 풀 리퀘스트를 생성합니다.
-
코드 리뷰: 모든 풀 리퀘스트는 최소 한 명의 팀원에 의해 리뷰되어야 합니다.
- 커밋 메시지: 명확하고 설명적인 커밋 메시지를 사용합니다.
- 브랜치 관리: 작업이 완료된 개인 브랜치는 주기적으로 정리합니다.
- 가상환경: .
venv/ - 환경파일:
.env - 설치파일:
requirements.txt - 버전파일:
.gitignore - 도커파일:
docker-compose.yml - 발표파일:
README.md, Wiki
- main 브랜치: 안정적인 코드베이스
- develop 브랜치: 개발 중인 기능 통합
- (작업자 이름)/(개발 app) 브랜치: 새로운 기능 개발
- 자동 수정: Black Formatter
- 시각화: GitLens
-
models.py -
serializers.py- serializer_class 속성으로 하나의 serializer 클래스를 지정합니다. 필요한 경우 action별로 다른 serializer를 사용할 수 있습니다.
- ModelSerializer를 사용하기로 합니다.
-
views.py- Mixins와 GenericAPIView를 같이 사용합니다.
-
urls.py- Router를 사용하여 여러 URL 패턴을 자동으로 생성합니다.
-
permissions.py -
test/- test 폴더 안에 앱마다 개별적으로 테스트 파일을 구현합니다.
통일된 형식보다는 길어도 상관없지만 기능을 유추할 수 있는 이름으로 용도를 명확히 해서 코드 가독성을 높입니다.
-
클래스명 (명사형)
- 대문자
-
메서드명 (동사형)
- 소문자
장고 프레임워크에서 작성한 주석 내용을 참고해서 작성합니다.
- 작성위치: 클래스명과 메서드명 하단
- 용도: 마우스를 갔다놓았을 때 보이는 코드 미리보기에서 주석으로 간단히 기능 확인 가능
- 언어: 팀원 간 원활한 소통을 위해 한국어로 작성 (단, 장고용어 중 번역이 어려운 용어는 외래어로작성)
메시지 유형에 상관없이 한국어로 작성합니다.
- 프론트엔드에서 사용자에게 제공할 메시지
- 서버에서 개발자 간 사용할 메시지
커밋 메시지 자세히 보기
커밋할 때 메시지는 아래 형식(title과 body)로 작성합니다. - 언어: 팀원 간 원활한 소통을 위해 한국어로 작성 (단, 장고용어 중 번역이 어려운 용어는 외래어로작성)type(scope): [타이틀 설명]
[바디 설명]
[푸터 설명]
- fix: 버그 수정
- feat: 새로운 기능 추가
- refactor: 버그 수정 또는 기능 추가하지 않는 코드 변경
- test: 테스트 추가 또는 기존 테스트 수정
- perf: 성능을 향상시키는 코드 변경
- ci: CI 구성 파일 및 스크립트의 변경사항
- build: 빌드 시스템 또는 외부 종속성에 영향을 미치는 변경사항
- style: 코드의 의미에 영향을 주지 않는 변경사항
- docs: 문서만 변경
- chore: 소스 코드, 테스트 파일 외 기타 변경사항
예시
"fix: 사용자 로그인 시 발생하는 404 오류 해결"
"feat: 사용자 프로필 사진 업로드 기능 구현"
"refactor: 사용자 인증 로직 개선"
"test: 사용자 등록 기능 단위 테스트 추가"
"perf: 데이터베이스 쿼리 최적화"
"ci: Travis CI 설정 변경"
"build: npm 패키지 업데이트"
"style: 들여쓰기 수정"
"docs: README.md 파일 업데이트"
"chore: .gitignore 파일 업데이트"
옵션이므로 생략 가능합니다.
auth - 인증 관련 변경사항 ui - 사용자 인터페이스 관련 변경사항 api - API 관련 변경사항 db - 데이터베이스 관련 변경사항 config - 설정 파일 관련 변경사항 docs - 문서화 관련 변경사항 tests - 테스트 관련 변경사항
"feat(auth): Google OAuth 통합"
"fix(ui): 모바일에서 버튼 오버랩 문제 해결"
"feat(api): 새로운 엔드포인트 추가 /users/preferences"
"perf(db): 사용자 조회 쿼리 최적화"
"chore(config): 개발 환경 설정 파일 업데이트"
"docs(api): API 문서에 새 엔드포인트 설명 추가"
"test(auth): 비밀번호 재설정 플로우 테스트 추가"
옵션이므로 생략 가능합니다.
Reviewed-by - 이 커밋을 검토한 사람의 이름을 나타냅니다. 용도: 코드 리뷰 프로세스를 추적하고, 변경사항에 대한 책임을 명확히 합니다.
Refs: #[이슈 번호] - 이 커밋과 관련된 이슈 또는 풀 리퀘스트의 참조 번호를 나타냅니다. 용도: 커밋을 특정 이슈나 작업 항목과 연결하여 추적성을 제공합니다.
BREAKING CHANGE: [설명] - 이 커밋이 이전 버전과 호환되지 않는 변경사항을 포함하고 있음을 나타냅니다. 용도: Semantic Versioning에서 주 버전(MAJOR) 증가를 트리거합니다.
Closes: #[이슈 번호] - 이 커밋으로 해결되는 이슈의 번호를 나타냅니다. 용도: 많은 이슈 트래킹 시스템에서 이 키워드를 인식하여 자동으로 이슈를 닫습니다.
Signed-off-by: [이름] <이메일> - 커밋 작성자의 서명을 나타냅니다. 용도: 일부 프로젝트에서는 법적 또는 절차적 이유로 이 서명을 요구합니다.
예시
Reviewed-by: John Doe
Refs: #456, #789
BREAKING CHANGE: 'port' 파라미터가 'url' 객체로 변경되었습니다.
Closes: #234
Signed-off-by: Jane Smith <[email protected]>
Footer