포스트

[TIL]2025-07-14 TextRPG - 팀 프로젝트 시작

[TIL]2025-07-14 TextRPG - 팀 프로젝트 시작

🗓️ TIL - 메인 : 팀 프로젝트로 만드는 TextRPG.

하하..이제 시작이라는 느낌이 드네.

✅ 오늘 한 일

  • 문자열 체크리스트 강의
  • 신규 프로젝트 Git 생성
  • 개발에서 이름의 중요성
  • 다이어그램,플로우차트,클래스 다이어그램

문자열 체크리스트 강의

문자열 조작 방법에 대해서 강의를 해주셨다.
하루하루 늘어가는 수많은 메서드들을 볼때마다 늘 고민된다.
저거 언제 다 외우지… 아니면 이해는 언제하지…
라는 고민할때쯤 하나씩 쳐보면서 이해해보기로했다.

메서드설명
ToUpper()대문자로 변환
ToLower()소문자로 변환
Trim()앞뒤 공백 제거
Replace()문자열 일부 바꾸기
Substring()일부 문자 추출
Insert()문자열 사이에 삽입
Remove()특정 위치 문자 삭제

문자열.jpg
사용방법이 어렵지는않지만 나만의 공식처럼 만들어볼까싶네.
변수.메서드(기능)
변수에 메서드를 적용시킨다라는 느낌이면 크게 어렵지는 않네.
라고 생각할때쯤 한번쯤은 수업들으면서 쳐봐야지.

trim.jpg
?? trim()하면 가운데 문자열도 없앨줄알았는데 왜 안없어지지..
tirm.jpg
이래서 뭐든 직접 타이핑을 해보는게 중요하군.

✅ 신규 프로젝트 Git 생성

신규 프로젝트 시작에 앞서 튜텨님이 Git 강의를 해주셨다.
여전히 햇갈리긴하지만 개념 정리를 한번 해주시니 좀 낫다는 생각이다.

브랜치란? -> 기존 코드를 보존하면서 새로운 기능을 개발할 수 있도록 하는 나뉜 버전.
나누는 이유? -> 기능 단위로 작업하기 위해.
Master 브랜치는? -> 가장 메인 브랜치. 배포용으로 씀.
develop 브랜치는? -> 개발 중인 모든 기능들이 모이는 중간 단계 브랜치.
feature 브랜치는? -> 기능 개발 브랜치.(좀 작은 단위)

commit 관련한 얘기도 해주셨는데 그동안은 commit할때 대충… 아무거나 쓰고있었다.
중요한건가? 싶어서 크게 의미 부여하면서 메시지를 작성하지않았지만
팀 단위로 협업할때는 많이 중요할듯싶다.

Prefix설명예시 커밋 메시지
feat새로운 기능 추가feat: add inventory system
fix버그 수정fix: resolve crash when loading empty slot
docs문서 관련 변경 (README, 주석 등)docs: update README with setup instructions
style코드 스타일 변경 (세미콜론, 들여쓰기 등 - 기능 변경 없음)style: fix indentation in GameManager
refactor리팩토링 (기능 변화 없이 코드 개선)refactor: simplify battle logic
perf성능 개선perf: improve loop speed in enemy AI
test테스트 코드 추가/수정test: add unit test for damage calculation
chore빌드, 설정, 도구 관련 작업 (배포 설정, 라이브러리 등)chore: update NuGet package Newtonsoft.Json
ciCI 관련 설정 변경 (GitHub Actions, Travis 등)ci: update build script to include tests
build빌드 시스템 수정 (예: gradle, npm, make 등)build: add msbuild debug profile
revert이전 커밋 되돌리기revert: fix: resolve crash when loading...

Prefix:(띄워쓰기)메시지 내용 :세미콜론 뒤에 한칸 띄워쓰기 필수!

✅ 개발에서 이름의 중요성

🥇간단 정리 카멜케이스, 파스칼케이스, 스네이크케이스 모두 프로그래밍에서 주로 사용하는 명명 규칙. 주로 변수나 함수의 이름을 지을 때 사용.

물론 이내용이 실질적인 코드에 영향을 주진않지만 협업할때를 위해서 하는 약속같은 개념인거같다.
(맞겠지..?)

케이스 이름형태 예시설명
🐪 camelCaseplayerScore첫 단어는 소문자, 이후 단어는 대문자로 시작
🐍 snake_caseplayer_score모든 단어를 소문자로, 단어 사이를 언더스코어로 구분
🥇 PascalCasePlayerScore모든 단어의 첫 글자를 대문자로 씀
㊙️ 번외(private)_playerHealthsnake + _ ,밑줄(_) + camelCase 형태

✅ 다이어그램,플로우차트,클래스 다이어그램

오늘이 협업 툴 관련해서 정말 많이 배운날인거같다.
다이어그램…플로우차트…클래스 다이어그램…다 뭐지?
처음 들어보는 내용이다.

☑️ 플로우 차트 -> 프로그램/프로세스의 흐름을 순서로 형태로 표현한것.
☑️ 와이어그램 -> UI의 기본 배치와 구조를 나타낸 설계도.
☑️ 클래스 다이어그램 -> 객체지향 설계에서 클래스 간의 구조와 관계를 표현.

플로우차트.jpg
플로우차트 : 내가 어떤것들은 구현하고 개발할건지? 이런 항목에 대해서 정리한다.
마을,상점,거래,전투,스킬 등등부터 시작해서 어떤 스텟을 가질건지?
무엇을 만들건지 이부분이 핵심이다.
와이어프레임.jpg
와이어프레임 : 플로우차트의 내용을 가지고 어떤식으로 만들건지? 만든다.
어떤 틀을 가지고 만들건지 정리하는 내용이다.
여기서 확실하게 잘 만들어줘야 다이어그램에서 개발하기 편해질듯하다.
클래스다이어그램.jpg
클래스다이어그램 : 와이어프레임에서 만든 요소에 뼈와 살을 붙이는 작업이다.
와이어프레임의 구조를 만들기위해 선언할 변수 및 클래스간 연계도? 라고 이해된다.

전투로 예로 들면 -> 스킬,장비,스텟 | 플레이어,몬스터라는 요소가 있다고 했을때
스킬,장비,스텟은 플레이어가 가진요소이며
스킬,스텟은 몬스터가 가진요소다.
그럼 여기서 최소한 스킬,스텟은 하나의 클래스에서 묶을수있다.
물론 더 세분화하면 플레이어의 클래스, 몬스터 클래스를 나눌수도있다.

여기서 한번 가정을 해볼까…
Character 라는 클래스를 놓고 플레이어 / 몬스터가 상속하게한다면
공통 요소로 쓸만한 변수는 뭐가 있을까…
HP, MP, 방어력, 공격력, 이름정를 상속하게 하고
각각 추가 요소는 오버라이딩으로 재정의 해볼수도있겠다. 😲

오늘은 TIL 작성하는데에도 많은 시간이 든만큼 참 숨가빳던 하루네.
자기전에 알고리즘 문제 하나만 풀고 자야겠다.
84번_사각형

  • 0714.End -
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.