CH 2 C++ 문법 주차 KPT 회고
✅ Keep (잘한 점 / 유지할 것)
도전·필수 과제 외에 추가 구현 아이디어를 적극 시도
주어진 가이드 구현에 그치지 않고, 직접 필요한 기능을 정의하고 확장하며 개발을 진행했다.
책임 분리(SRP)를 기준으로 구조를 지속적으로 정리
Loader / Factory / EffectSystem·Manager / Inventory로 역할을 분리하며,
설계 변경이 반복되는 상황에서도 구조를 점진적으로 안정화했다.
책임이 과도해진 클래스들을 분리해 관리하려는 시도
일부 클래스에 로직이 집중되는 문제를 인식하고, 역할을 나누며 구조를 개선했다.
아이템·드랍을 데이터 기반으로 설계
아이템 정보, 효과, 드랍 규칙을 dat 파일로 분리해
코드 수정 없이 콘텐츠 변경·확장이 가능하도록 했다.
Inventory의 책임을 명확히 제한
소유·선택만 담당하고, 실제 효과 적용은 EffectSystem/Manager에 위임해 결합도를 낮췄다.
드랍 시스템을 규칙 / 원본 / 적용으로 분리
RewardRepository / DropTable / RewardManager·BattleRewardService로 나누어
드랍 흐름이 명확해지고 디버깅이 쉬워졌다.
BattleResult로 보상 결과를 일원화
전투·보상·UI 연동 구조가 단순해졌다.
설계 변경 과정을 통해 구조를 개선한 경험
아이템과 인벤토리가 여러 시스템과 연결되며 설계가 자주 바뀌었지만,
그 과정에서 책임 경계와 역할 분리가 더 명확해졌다.
⚠️ Problem (문제 / 아쉬운 점)
초기 설계가 충분하지 않아 설계 변경과 코드 수정이 반복됨
기능 구현 위주로 시작하면서 중복 코드가 발생했고, 이후 재정리 작업이 필요했다.
아이템/인벤토리의 높은 연관도로 충돌 문제 발생
전투·상점·드랍·UI 등과 자주 연동되며 수정 시 영향 범위가 컸다.
설계 미숙으로 코드 재구성이 여러 번 발생
구현 이후 SOLID 원칙을 지키기 위해 기존 코드를 다시 분해·이동하는 과정이 쉽지 않았다.
raw pointer 기반 소유권 관리의 위험
이중 delete, 메모리 누수 가능성이 남아 있다.
Effect/Rule 확장 시 분기 복잡도 증가 가능성
보상 관련 클래스 역할이 문서상 혼동될 여지
dat 파싱 예외 처리 및 테스트 부족
🚀 Try (다음에 시도할 것 / 개선 방향)
초기 설계 단계에 더 많은 시간 투자
구조를 먼저 충분히 고민해, 이후 재설계로 소요되는 시간을 줄이기.
SOLID 원칙을 사전에 반영해 클래스 구성
구현 후 수정이 아닌, 설계 단계에서 책임 경계를 명확히 설정.
연결 지점이 많은 도메인부터 설계 경계 고정
아이템/인벤토리처럼 영향 범위가 넓은 영역을 우선 확정.
아이템·드랍 접근을 서비스 계층으로 제한
소유권 정책을 unique_ptr 등으로 코드 레벨에서 강제
규칙 로직을 테이블/전략 패턴으로 개선
Effect 처리 타이밍·만료 정책 명확화
dat 로더 예외 처리 및 테스트 보강
git 커밋을 작은 단위로 자주 진행
변경 이력을 명확히 하고, 되돌리기 쉬운 흐름 유지.
