[TIL]2025-07-14 TextRPG - 팀 프로젝트 시작
🗓️ TIL - 메인 : 팀 프로젝트로 만드는 TextRPG.
하하..이제 시작이라는 느낌이 드네.
✅ 오늘 한 일
- 문자열 체크리스트 강의
- 신규 프로젝트 Git 생성
- 개발에서 이름의 중요성
- 다이어그램,플로우차트,클래스 다이어그램
문자열 체크리스트 강의
문자열 조작 방법에 대해서 강의를 해주셨다.
하루하루 늘어가는 수많은 메서드들을 볼때마다 늘 고민된다.
저거 언제 다 외우지… 아니면 이해는 언제하지…
라는 고민할때쯤 하나씩 쳐보면서 이해해보기로했다.
| 메서드 | 설명 |
|---|---|
ToUpper() | 대문자로 변환 |
ToLower() | 소문자로 변환 |
Trim() | 앞뒤 공백 제거 |
Replace() | 문자열 일부 바꾸기 |
Substring() | 일부 문자 추출 |
Insert() | 문자열 사이에 삽입 |
Remove() | 특정 위치 문자 삭제 |

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

?? trim()하면 가운데 문자열도 없앨줄알았는데 왜 안없어지지..

이래서 뭐든 직접 타이핑을 해보는게 중요하군.
✅ 신규 프로젝트 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 |
ci | CI 관련 설정 변경 (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:(띄워쓰기)메시지 내용 :세미콜론 뒤에 한칸 띄워쓰기 필수!
✅ 개발에서 이름의 중요성
🥇간단 정리 카멜케이스, 파스칼케이스, 스네이크케이스 모두 프로그래밍에서 주로 사용하는 명명 규칙. 주로 변수나 함수의 이름을 지을 때 사용.
물론 이내용이 실질적인 코드에 영향을 주진않지만 협업할때를 위해서 하는 약속같은 개념인거같다.
(맞겠지..?)
| 케이스 이름 | 형태 예시 | 설명 |
|---|---|---|
| 🐪 camelCase | playerScore | 첫 단어는 소문자, 이후 단어는 대문자로 시작 |
| 🐍 snake_case | player_score | 모든 단어를 소문자로, 단어 사이를 언더스코어로 구분 |
| 🥇 PascalCase | PlayerScore | 모든 단어의 첫 글자를 대문자로 씀 |
| ㊙️ 번외(private) | _playerHealth | snake + _ ,밑줄(_) + camelCase 형태 |
✅ 다이어그램,플로우차트,클래스 다이어그램
오늘이 협업 툴 관련해서 정말 많이 배운날인거같다.
다이어그램…플로우차트…클래스 다이어그램…다 뭐지?
처음 들어보는 내용이다.
☑️ 플로우 차트 -> 프로그램/프로세스의 흐름을 순서로 형태로 표현한것.
☑️ 와이어그램 -> UI의 기본 배치와 구조를 나타낸 설계도.
☑️ 클래스 다이어그램 -> 객체지향 설계에서 클래스 간의 구조와 관계를 표현.

플로우차트 : 내가 어떤것들은 구현하고 개발할건지? 이런 항목에 대해서 정리한다.
마을,상점,거래,전투,스킬 등등부터 시작해서 어떤 스텟을 가질건지?
무엇을 만들건지 이부분이 핵심이다.

와이어프레임 : 플로우차트의 내용을 가지고 어떤식으로 만들건지? 만든다.
어떤 틀을 가지고 만들건지 정리하는 내용이다.
여기서 확실하게 잘 만들어줘야 다이어그램에서 개발하기 편해질듯하다.

클래스다이어그램 : 와이어프레임에서 만든 요소에 뼈와 살을 붙이는 작업이다.
와이어프레임의 구조를 만들기위해 선언할 변수 및 클래스간 연계도? 라고 이해된다.
전투로 예로 들면 -> 스킬,장비,스텟 | 플레이어,몬스터라는 요소가 있다고 했을때
스킬,장비,스텟은 플레이어가 가진요소이며
스킬,스텟은 몬스터가 가진요소다.
그럼 여기서 최소한 스킬,스텟은 하나의 클래스에서 묶을수있다.
물론 더 세분화하면 플레이어의 클래스, 몬스터 클래스를 나눌수도있다.
여기서 한번 가정을 해볼까…
Character 라는 클래스를 놓고 플레이어 / 몬스터가 상속하게한다면
공통 요소로 쓸만한 변수는 뭐가 있을까…
HP, MP, 방어력, 공격력, 이름정를 상속하게 하고
각각 추가 요소는 오버라이딩으로 재정의 해볼수도있겠다. 😲
오늘은 TIL 작성하는데에도 많은 시간이 든만큼 참 숨가빳던 하루네.
자기전에 알고리즘 문제 하나만 풀고 자야겠다.
84번_사각형
- 0714.End -