과제 체크포인트

기본과제

• 코드가 Prettier를 통해 일관된 포맷팅이 적용되어 있는가?
• 적절한 줄바꿈과 주석을 사용하여 코드의 논리적 단위를 명확히 구분했는가?
• 변수명과 함수명이 그 역할을 명확히 나타내며, 일관된 네이밍 규칙을 따르는가?
• 매직 넘버와 문자열을 의미 있는 상수로 추출했는가?
• 중복 코드를 제거하고 재사용 가능한 형태로 리팩토링했는가?
• 함수가 단일 책임 원칙을 따르며, 한 가지 작업만 수행하는가?
• 조건문과 반복문이 간결하고 명확한가? 복잡한 조건을 함수로 추출했는가?
• 코드의 배치가 의존성과 실행 흐름에 따라 논리적으로 구성되어 있는가?
• 연관된 코드를 의미 있는 함수나 모듈로 그룹화했는가?
• ES6+ 문법을 활용하여 코드를 더 간결하고 명확하게 작성했는가?
• 전역 상태와 부수 효과(side effects)를 최소화했는가?
• 에러 처리와 예외 상황을 명확히 고려하고 처리했는가?
• 코드 자체가 자기 문서화되어 있어, 주석 없이도 의도를 파악할 수 있는가?
• 비즈니스 로직과 UI 로직이 적절히 분리되어 있는가?
• 코드의 각 부분이 테스트 가능하도록 구조화되어 있는가?
• 성능 개선을 위해 불필요한 연산이나 렌더링을 제거했는가?
• 새로운 기능 추가나 변경이 기존 코드에 미치는 영향을 최소화했는가?
• 코드 리뷰를 통해 다른 개발자들의 피드백을 반영하고 개선했는가?
• (핵심!) 리팩토링 시 기존 기능을 그대로 유지하면서 점진적으로 개선했는가?

심화과제

• 변경한 구조와 코드가 기존의 코드보다 가독성이 높고 이해하기 쉬운가?
• 변경한 구조와 코드가 기존의 코드보다 기능을 수정하거나 확장하기에 용이한가?
• 변경한 구조와 코드가 기존의 코드보다 테스트를 하기에 더 용이한가?
• 변경한 구조와 코드가 기존의 모든 기능은 그대로 유지했는가?
• (핵심!) 변경한 구조와 코드를 새로운 한번에 새로만들지 않고 점진적으로 개선했는가?

과제 셀프회고

유쾌한_클린코드

클린 코드라는 것을 직접적으로 체험 해보지 못 했었다. 회사 업무에서도 마냥 흘려 듣기만 했다. 그리고 내가 코드를 짜면서도 '그냥 보기좋고 깔끔하게 짜면 되는거 아냐?' 라는 생각으로 코드를 만들었다. 과제를 하면서 정말 더닝크루거효과 를 제대로 느꼈다. (나는 정말 무식하게 용감하게 코드를 짰구나. 정말 앞뒤 맥락 없이!)

과제를 하면서 내가 제일 신경 쓴 부분은 무엇인가요?

코딩 컨벤션 또는 코딩 가이드라인

실제로 회사 프로젝트를 하면서 코딩 컨벤션을 따로 정하지 않고 있었다. 그래서 이번 과제를 하면서는 코딩 컨벤션에 관심이 생기고 최대한 지켜보자 라는 마음으로 임했다. 물론 AI 가 상당 부분을 도와줬지만, 그렇게함으로써 나 혼자 하는 것보다 질적으로 높은 수준으로 과제를 이끌어 갈 수 있었다고 생각한다. (물론 AI 를 완벽하다고 생각하진 않지만, 적어도 나보단 낫다.) 다음엔 팀원들과 코딩 컨벤션에 대해서 얘기를 나눠보면 좋겠단 생각을 했다.

가이드: Frontend Fundamentals ; 변경하기 쉬운 프론트엔드 코드를 위한 지침서

마일스톤

그리고 나는 완전히 AI-driven 방식으로 과제를 진행했고, 내 손으로 코드를 바꾼 건은 맹세코 단 한 건도 없다. 그래서 더 더욱 마일스톤 을 남기는 것에 집착했다. 내 손으로 코드를 치는 것이 아니니까 돌아올 수 없는 강을 건너지 않도록 혹은 딴 길로 새지 않도록 기능별 또는 구조별 작업이 완료되면 커밋 을 이행하여 자취를 정확히 남겼다. 만약을 대비한 롤백을 위함도 있었다. (사실 이게 제일 큼)

AI 툴: Cursor:The AI Code Editor

히스토리 관리

또한, 한가지 더 커밋보다 광적으로 집착한 것은 기록이였다. 모든 작업이 끝나면 내가 AI 에게 요청한 내역, AI가 완료한 내역, 궁금증, 트러블 슈팅등 이 과제를 이루기 위한 모든 행위들을 기록했다. (물론 AI가 기록했다.) PR 및 회고의 이유도 있지만, 타임라인 순으로 기록된 내역들을 AI 가 확인하고 같은 작업을 N 번 반복 하지 않게 만들었다. 똑같은 말 다시 안하게 하는 것이 과제 진행 속도에 영향을 많이 끼칠 것이라고 판단했다. 덕분에 내 기준보다 과제를 빨리 끝마친 것도 있다. (질적인 것보다 제출 및 체험을 우선으로 생각했다.)

<히스토리 내역 중 일부>

# 리팩토링 히스토리

## 완료된 작업

### 2025-07-30: 중복 코드 제거 및 헬퍼 함수 도입

- **작업 내용**: 중복되는 DOM 요소 검증 로직을 `getRequiredElement`, `getRequiredProduct` 헬퍼 함수로 통합
- **개선 효과**: 코드 중복 제거, 에러 처리 일관성 확보
- **테스트 결과**: ✅ 모든 테스트 통과 (87 passed, 16 skipped)

### 2025-07-30: 데이터 모델 분리 및 모듈화

- **작업 내용**:
 - `src/basic/modules/data/productData.js` 생성
 - 상품 데이터, 상수, 유틸리티 함수들을 별도 모듈로 분리
 - `PRODUCT_CONSTANTS`, `DISCOUNT_RATES`, `POINTS_CONFIG`, `TIMING_CONFIG` 등 상수화
- **개선 효과**: 데이터와 비즈니스 로직 분리, 재사용성 향상
- **테스트 결과**: ✅ 모든 테스트 통과 (87 passed, 16 skipped)

### 2025-07-30: 서비스 모듈화 완료

- **작업 내용**:
 - `src/basic/modules/services/discountService.js` 생성 - 할인 계산 로직 분리
 - `src/basic/modules/services/loyaltyService.js` 생성 - 포인트 계산 로직 분리
 - `src/basic/modules/cart/cartState.js` 생성 - 장바구니 상태 관리 분리
- **개선 효과**: 비즈니스 로직 모듈화, 단일 책임 원칙 적용
- **테스트 결과**: ✅ 모든 테스트 통과 (87 passed, 16 skipped)

### 2025-07-30: UI 렌더링 로직 분리 완료

- **작업 내용**:
 - `src/basic/modules/ui/uiRenderer.js` 생성 - DOM 생성 함수들을 컴포넌트로 분리
 - `Header`, `ProductSelector`, `CartDisplay`, `OrderSummary`, `ManualOverlay`, `CartItem` 컴포넌트화
 - 컴포넌트 네이밍 규칙을 `MyComponent` 형태로 통일 (React 호환성)
- 이벤트 리스너 중앙화로 관심사 분리
- **개선 효과**: UI 로직과 비즈니스 로직 완전 분리, React 마이그레이션 준비
- **테스트 결과**: ✅ 모든 테스트 통과 (87 passed, 16 skipped)

과제를 다시 해보면 더 잘 할 수 있었겠다 아쉬운 점이 있다면 무엇인가요?

이번에 팀원들과 코드에 대해 많은 얘기를 나누지 못해서 다시 한다면 팀원들의 의견을 듣고 코드에 적용 해보고 싶다. 그리고 위에 적은 '히스토리 관리'를 좀 더 나의 개성을 넣어 만들어 보면 어땠을까 라는 생각을 지금 PR을 작성하면서 하게 됐다. 준일 코치 멘토링 때 주제는 기억이 안나지만 테오봇, 준일봇, 오프봇, 성호봇을 만들어서 ~~~ 해보고 ~~~ 하면 ~~ 개쩔지? 이런 답변을 해줬다. (개쩔지? 란 단어는 안썼는데 그런 뉘앙스였음.)

그래서 나의 개성이 문서화가 되어 AI 한테 적용을 시키면 정석봇 이랑 페어코딩을 하면 흥미로울 것 같고 내가 원하는 개발 방향을 잘 이해해주고 추천도 잘 해줄 것 같다는 생각이 들었다. 그래서 기록에 조금 더 신경을 쓰는 방향으로 과제를 진행해봐야겠다.

그리고 AI 로 테스트 코드를 짜보긴 했는데 시간이 없어서 해당 테스트를 만들고 통과를 하는 코드를 작성하지 못했다. 테스트 코드가 있었다면 좀 더 촘촘한 프로젝트가 될 수 있지 않았을까? 라는 생각이 든다.

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)

심화과제로 리액트 + 타입스크립트를 적용해봤습니다. 리액트를 사용을 하지 않는 저에게는 지금 프로젝트 구조가 (src/advanced/**/*) 익숙치 않습니다. 현재는 도메인 중심 설계(Domain-Driven Design) 로 분류를 해놨는데 이 방식이 보편화가 된 방식인지 궁금합니다. 혹은 코치님이 선호하는 구조가 있는지, A 같은 성향의 프로젝트엔 A` 구조 같은 공식이 있는지도 궁금합니다.

src/advanced/

├── 📄 App.tsx # 메인 애플리케이션 컴포넌트 ├── 📄 main.tsx # React 앱 진입점 ├── 📄 index.css # 전역 스타일 │ ├── 🗂️ components/ # 도메인별 컴포넌트 구조 │ ├── 🛒 cart/ # 장바구니 도메인 │ │ ├── 📄 CartContainer.tsx # 장바구니 컨테이너 │ │ ├── 📄 CartItem.tsx # 장바구니 아이템 │ │ └── 📄 index.ts # Barrel export │ │ │ ├── 📦 product/ # 상품 도메인 │ │ ├── �� ProductSelector.tsx # 상품 선택기 │ │ ├── 📄 StockStatus.tsx # 재고 상태 표시 │ │ └── 📄 index.ts # Barrel export │ │ │ ├── 🛍️ order/ # 주문 도메인 │ │ ├── 📄 index.ts # Barrel export │ │ └── 📁 OrderSummary/ # 주문 요약 │ │ ├── 📄 index.tsx # 주문 요약 메인 │ │ └── �� DiscountSection.tsx # 할인 섹션 │ │ │ ├── 🔧 common/ # 공통 UI 컴포넌트 │ │ ├── 📄 Header.tsx # 헤더 컴포넌트 │ │ ├── 📄 DiscountIcon.tsx # 할인 아이콘 │ │ ├── 📄 index.ts # Barrel export │ │ └── 📁 Toast/ # 토스트 알림 │ │ ├── 📄 Toast.tsx # 토스트 컴포넌트 │ │ ├── �� ToastContainer.tsx # 토스트 컨테이너 │ │ └── 📄 types.ts # 토스트 타입 정의 │ │ │ └── ❓ help/ # 도움말 도메인 │ ├── 📄 index.ts # Barrel export │ └── 📁 HelpModal/ # 도움말 모달 │ ├── 📄 index.tsx # 도움말 모달 메인 │ └── 📄 PolicySection.tsx # 정책 섹션 │ ├── 🔄 contexts/ # React Context │ ├── 📄 ToastContext.tsx # 토스트 상태 관리 │ └── 📄 TimerContext.tsx # 타이머 상태 관리 │ ├── 🎣 hooks/ # 커스텀 훅 │ ├── 📄 useCart.ts # 장바구니 훅 │ ├── �� useErrorHandler.ts # 에러 처리 훅 │ ├── 📄 useModal.ts # 모달 훅 │ └── 📄 useProductSelection.ts # 상품 선택 훅 │ ├── ⚙️ services/ # 비즈니스 로직 서비스 │ ├── 📄 cartService.ts # 장바구니 서비스 │ ├── 📄 loyaltyService.ts # 포인트 서비스 │ ├── �� discountService.ts # 할인 서비스 │ └── 📄 timerService.ts # 타이머 서비스 │ ├── 📊 types/ # TypeScript 타입 정의 │ └── 📄 index.ts # 중앙화된 타입 정의 │ ├── 🛠️ utils/ # 유틸리티 함수 │ ├── 📄 errorHandler.ts # 에러 핸들러 │ ├── 📄 errorFactory.ts # 에러 팩토리 │ └── 📄 discountUtils.ts # 할인 유틸리티 │ ├── 📁 data/ # 데이터 레이어 │ └── 📄 productData.ts # 상품 데이터 │ └── 📋 constants/ # 상수 정의 ├── 📄 index.ts # 중앙화된 상수 └── 📄 businessRules.ts # 비즈니스 규칙