Text RPG 팀플 발표 | 코드 카타 (Code Kata) 콜라 문제 

 

 

Text RPG 팀플 발표 

자료

Git 링크: https://github.com/steampower33/TEAM8-Text-Console-RPG

Youtube: https://www.youtube.com/watch?v=Smd5yC0MmSY

PPT: https://gamma.app/docs/8-vji69xyox5ji9cf?mode=doc

학원에서 제시한 구도

트러블 슈팅

  • 매번마다 파일 추가하면 .vcxproj 충돌 → CMakelists.txt 바꿈
  • Branch Rules
    • 한명이 독단적으로 pull request & merge로 날려버리는 위험성을 방지하기위해서 2명이상의 승인이 필요하도록 설정
  • git convention
    • branch 이름을 대소문자구분해서 이름을 짓다가 branch 이름 충돌? 이 발생함
    • 그래서 대소문자 구분을 하지않고 이름을 짓기로 결정

 

Team Code Convention

📨 환경 설정

  • Rider : 2026.1

명명 규칙

  1. 다른 사람이 맡은 코드는 임의로 고치지 말고 꼭 담당자랑 얘기하기
  2. 코드 리팩토링 하기 전에는 리팩토링 담당자가 팀 전체에 공유하기
  3. PR 올리기 전 두 가지 꼭 하기
    • 코드 정렬: Ctrl+Alt+L
    • 불필요한 import 제거: Ctrl+Alt+O(알파벳 O)
  4. 주석은 // 만 사용하기
  5. UE5 명명법 - C++ 명명 규칙 (UE5 스타일 + 매개변수 커스텀)
    • 클래스 이름 (Class)
      • 규칙: 파스칼 케이스 (첫 글자 대문자)
      • 예시: class SpiderManager, class Weapon
    • 함수 이름 (Function)
      • 규칙: 파스칼 케이스 (첫 글자 대문자)
      • 예시: void CalculateDamage(), void SetupInput()
    • 일반 변수 이름 (Variable)
      • 규칙: 파스칼 케이스 (첫 글자 대문자)
      • 예시: int TargetYaw, float CurrentSpeed
    • 퍼블릭 멤버 변수 (Public Member)
      • 규칙: 파스칼 케이스 (첫 글자 대문자, 접두사 없음)
      • 예시: float MaxSpeed
    • 프라이빗 멤버 변수 (Private Member)
      • 규칙: 파스칼 케이스 (첫 글자 대문자, m_ 같은 접두사 사용 안 함)
      • 예시: FVector CleanVelocity
    • 상수 이름 (Constant)
      • 규칙: 전체 대문자 (단어 구분은 대문자로 이어 붙임 또는 일반적으로 스네이크 표기)
      • 예시: const int MAXSPEED, const float TRACEDISTANCE (설정값 UpperCase 기준)
    • 매개변수 이름 (Parameter)
      • 규칙: 소문자 스네이크 케이스 (전체 소문자, 단어 구분에 언더바 _ 사용)
      • 예시: void AddInput(float delta_time, int scale_value)
  6. 서브 브랜치 네이밍
    • feat/~
    feature, 기능구현 시
    • fix/~
    fix, 기능 및 버그 수정 시
    • chore/~
    빌드 설정, 의존성 추가/삭제/수정 시
    • docs/~
    문서 추가/삭제/수정 시
    • refac/~
    폴더구조, 기능 등 리팩토링 시
    • ci/~
    workflow 수정 시
    • hotfix/~
    dev branch 건너뛰고 즉시 main branch merge 필요할 경우

로직 작성 규칙

  1. 일반적인 Manager / Component / Subsystem 클래스에는 불필요한 인터페이스를 추가 X
    • 현재 구조에서 도입 이유와 이점이 명확할 때만 팀 논의 후 적용
  2. 중복되는 로직은 공통 함수로 분리하기
    • 같은 클래스 내부의 중복은 private 함수로 추출하고
    • 여러 클래스에서 반복되는 경우 Utility / Helper / Function Library 등으로 분리한다
  3. namespace는 header에 포함하지않는다.
  4. header에는 전방 선언, cpp파일에 다른 클래스의 header를 포함한다.

🐱 Git / GitHub 컨벤션

.gitignore 관련

  1. 비밀번호 등등 민감한 정보가 GitHub에 올라가지 않도록 주의하기
  2. .gitignore에 추가되어야 하는 항목
    • Rider
    • VisualStudio

commit message

- feat	     해당 파일에 새로운 기능이 생김
- add	       없던 파일을 생성함, 초기 세팅
- fix	       버그 수정
- refactor	 코드 리팩토링
- move	     파일 옮김/정리
- delete	   기능/파일 삭제
- test	     테스트 코드 작성
- gitfix	   gitignore 수정
- script	   build.gradle 변경, docker compose 변경
- chore	     주석 추가 및 수정, 변수명 및 클래스명 수정
- improve	   개선

 

branch

  1. release + 버전→ 배포 브랜치 - main
  2. dev → 통합 개발 브랜치
  3. 형식
  4. ex. 기능 추가: feat/{기능 설명} // feat/car-drift-system // feat/item-missile ex. 버그 수정: fix/{짧은 설명} // fix/ai-not-moving // fix/crash-on-map-load ex. 리팩토링: refactor/{리팩터링 짧은 설명} // refactor/car-physics // refactor/item-system ex. 테스트 코드: test/{짧은 설명} ex. 맵 작업: map/{맵 이름} ex. 문서 관리: docs/readme
  5. 추가로 설명을 써야 할 때에는 하이픈(-) 사용하기
    • 하이픈 (hypen) (-) (O)
    • 언더바 (under bar) (_) (X)
    • 대시 (dash) (—) (X)

Pull Request

  1. Pull Request Template 사용하기
  2. 최대한 다 코드 리뷰 해보기
  3. Pull Request Template 작성 시 유의 사항
    • 팀장님 포함 리뷰어를 3명 이상 지목하기
    • 최소 단위로 commit 및 push하기
    • 최소 단위로 PR 하기
      • 아무리 많아도 2개 초과하지 않도록 주의하기
  4. PR 전에 반드시 Postman 실행하여 잘 작동하는지 테스트하기
  5. 최소 단위가 헷갈릴 때는 ‘검토할 상대방에게 부담되지 않는가?’ 스스로 질문하기 PR 올리기
  6. PR이 지연되면, dev에서 새 브랜치를 생성한 다음 직전 브랜치를 pull하기

기타 사항

  1. 로그 기록이 필요하겠다 싶은 부분은 회의 안건으로 올려주기
  2. 프로젝트 1주 차 지난 뒤에 다 같이 보면서 피드백하기
  3. 테스트 코드가 정말 필요하겠다 싶은 로직은 개발 중 // 테스트 코드 작성 필요 주석 남기기
  4. 나중에 작업할 부분이나 논의가 필요한 부분 등등 // todo 주석 꼭 남기기

Assets

Visuals (ASCII Art): Text to ASCII Art Generator: Create ASCII Art from Text

Sound

협업 툴

 

코드 카타 (Code Kata) 콜라 문제 

 

052. 콜라 문제 | Solved Date: 2026-05-29-Fri | Problem Link

 

저작자표시 동일조건 (새창열림)
  • hELLO · Designed By 정상우.v4.10.6

    • 티스토리툴바