192 lines
9.4 KiB
Markdown
192 lines
9.4 KiB
Markdown
---
|
|
title: daily-task / develop / {{slug}}
|
|
source_type: daily-task
|
|
track: develop
|
|
status: raw
|
|
status_label: not-started
|
|
difficulty: intermediate
|
|
duration_estimate: 120
|
|
prerequisites: []
|
|
parent_project: ca-skeleton-operational-contract
|
|
parent_branch:
|
|
target_date: YYYY-MM-DD
|
|
created: YYYY-MM-DD
|
|
tags: [daily-task]
|
|
# 트랙 구분은 폴더 경로 + frontmatter `track:` 가 SSOT. tag 에 develop/infra 중복 금지.
|
|
# 추가 tag 는 도메인별 (예: `validation`, `testing`, `archunit`) 1~2개 권장.
|
|
---
|
|
|
|
# daily-task / develop / {{slug}}
|
|
|
|
> Layer: `raw/daily-tasks/develop/` — **개발 트랙 일일 실습 과제**. 사수가 신입에게 주는 형식의 자율 학습 과제. 매일 아침 1개 수행.
|
|
> `status_label`: `not-started` | `in-progress` | `done` | `abandoned`
|
|
> `difficulty`: `starter` (오늘이 처음) | `intermediate` (기본 흐름 익숙) | `advanced` (실패 모드 / 트레이드오프 탐구)
|
|
> `duration_estimate`: 분 단위. 기본 120분 (Pomodoro 4-5개). 단순 일정이 아니라 *완료 신호가 뜰 때까지* 의 자기 추정치.
|
|
>
|
|
> **체계 근거**: 본 template 구조는 두 raw 자료로 정당화된다 — 9-section anchor 는 vendor-normative 가이드 (`[[raw/company-tech-blogs/skillable-hands-on-lab-structure]]`), 단계 분할·자기평가·회고 원리는 deliberate-practice 개인 블로그 (`[[raw/company-tech-blogs/deliberate-practice-software-developers-redgreencode]]`) 기반. 두 자료 모두 *공식 best practice 가 아니다* — 본 template 도 best practice 가 아닌 **운영 가능한 학습 구조**로만 인용할 것.
|
|
|
|
## 부모 (필수)
|
|
|
|
- **Parent project**: `[[raw/project-notes/ca-skeleton-operational-contract]]` (또는 해당하는 다른 project-note)
|
|
- **연관 branch** (선택, 있을 때만): `[[raw/branch-notes/{{branch-slug}}]]`
|
|
|
|
> 본 과제가 어느 작업 묶음에 속하는지 명시. parent 없는 과제는 금지 (raw 영구 보관 정책 + ingest 시 추적 불가).
|
|
|
|
## 1. 학습 목표
|
|
|
|
> 3-5개 측정 가능 목표. "이 과제 끝났을 때 다음을 *할 수 있어야* 한다" 형식.
|
|
> 근거: `[[raw/company-tech-blogs/skillable-hands-on-lab-structure]]#SKILL-LAB-C1` — Learning Objectives 는 hands-on lab 의 7 functional spec 중 첫 anchor.
|
|
|
|
- [ ] L1: <할 수 있어야 하는 것 — 동사로 시작 (예: "ArchUnit rule 로 controller→domain 직접 의존을 빌드 실패로 검출할 수 있다")>
|
|
- [ ] L2: <...>
|
|
- [ ] L3: <...>
|
|
|
|
## 2. 스토리라인
|
|
|
|
> *왜* 이 과제가 필요한가. 실무 시나리오 1-2 문단. 단순한 코드 따라치기를 막는 anchor.
|
|
> 근거: `[[raw/company-tech-blogs/skillable-hands-on-lab-structure]]#SKILL-LAB-C2` — storyline 이 없으면 lab 은 "clicking things" 가 되고 학습자는 skill 향상 없이 끝난다.
|
|
|
|
(예시: "ca-tmpl 의 `feature-boundary-validation-mapping-contract` branch D7 결정 — controller 가 domain object 를 직접 반환하지 않는다 — 을 ArchUnit 으로 강제하려 한다. 다음 신입이 그 결정을 모르고 controller method 의 return type 에 domain entity 를 넣어도 build 가 통과되면 boundary contract 가 사실상 무력화된다. 오늘은 그 단 한 가지 시나리오만 막는 rule 을 작성하고 의도적인 위반으로 빌드를 깬다.")
|
|
|
|
## 3. 환경
|
|
|
|
> 사용 도구·버전·사전 셋업.
|
|
> 근거: `[[raw/company-tech-blogs/skillable-hands-on-lab-structure]]#SKILL-LAB-C1` — Prospective environment + Technologies used.
|
|
|
|
**개발 도구**:
|
|
|
|
- Java: <버전, e.g., 21 LTS>
|
|
- Build: <Gradle 8.x / Maven 3.9>
|
|
- IDE 권장: <IntelliJ IDEA 2025.x>
|
|
- 추가 라이브러리: <ArchUnit / MapStruct / RestAssured 등 — 버전 명시>
|
|
|
|
**사전 셋업**:
|
|
|
|
```bash
|
|
# repo clone / branch 전환
|
|
cd ~/workspace/ca-tmpl
|
|
git checkout -b daily-task/develop/{{slug}}
|
|
|
|
# 빌드 확인
|
|
./gradlew clean build
|
|
```
|
|
|
|
**예상 디렉토리 변경**:
|
|
|
|
- 추가/수정될 파일 경로 미리 명시 (예: `adapter-web/src/test/java/.../CleanArchitectureTest.java`)
|
|
|
|
## 4. 사전 지식
|
|
|
|
> 알아야 할 개념·결정. 모르면 wikilink 먼저 정독한 뒤 진행.
|
|
|
|
- `[[wiki/concepts/<concept-slug>]]` — <왜 필요한지 한 줄>
|
|
- `[[raw/branch-notes/<related-branch>]]` — <관련 결정>
|
|
- `[[raw/official-docs/<source-slug>]]` — <인용할 claim>
|
|
|
|
## 5. 단계별 과제
|
|
|
|
> Pomodoro (~25분) 단위로 분할. 각 단계는 *현재 능력보다 약간 높은* 도전이어야 한다 — 너무 쉬우면 학습 0, 너무 어려우면 좌절.
|
|
> 근거: `[[raw/company-tech-blogs/deliberate-practice-software-developers-redgreencode]]#DP-RGC-C2` (slightly higher than current ability — Ericsson 연구의 *개인 블로그 2차 인용*. 공식 best practice 표현 금지), `#DP-RGC-C5` (25-min Pomodoro 는 권고 시작점일 뿐 규범 아님).
|
|
|
|
### Step 1: <단계 제목> (~25min)
|
|
|
|
- **무엇을 (What)**: <구현해야 할 단위. 단일 commit 이 떠올라야 함>
|
|
- **어떻게 (How — hint, *spoiler 아님*)**: <어떤 클래스를 만져야 하는지 / 어떤 패턴을 찾아야 하는지. 코드 정답 X>
|
|
- **합격 신호 (Done when)**: <이 단계가 끝났음을 어떻게 알 수 있는가 — 명령어 / 로그 / 빨강↔초록 전환 / test name>
|
|
|
|
### Step 2: <단계 제목> (~25min)
|
|
|
|
- **What**:
|
|
- **How (hint)**:
|
|
- **Done when**:
|
|
|
|
### Step 3: <단계 제목> (~25min)
|
|
|
|
- **What**:
|
|
- **How (hint)**:
|
|
- **Done when**:
|
|
|
|
### 실패 모드 탐구> (~25min)
|
|
|
|
- **What**:
|
|
- **How (hint)**:
|
|
- **Done when**:
|
|
|
|
> *단계 갯수는 difficulty 에 따라*: starter=2, intermediate=3-4, advanced=4-5. 총 시간은 frontmatter `duration_estimate` 와 일치.
|
|
|
|
## 6. 검증
|
|
|
|
> 객관적 합격 기준. 단계 통과 = 측정 가능한 contract. *느낌* 으로 끝내지 않는다.
|
|
> 근거: `[[raw/company-tech-blogs/skillable-hands-on-lab-structure]]#SKILL-LAB-C4` (assessment = immediate feedback for success / additional help), `[[raw/company-tech-blogs/deliberate-practice-software-developers-redgreencode]]#DP-RGC-C3` (objective standard 로 평가 — 단 "objective standard" 의 구체 정의는 본 template 작성자가 합격 명령어로 조작적 정의해야 함).
|
|
|
|
**자동 검증**:
|
|
|
|
```bash
|
|
# 1) 빌드 + 단위 테스트
|
|
./gradlew clean build test
|
|
# 합격 기준: exit code 0
|
|
|
|
# 2) ArchUnit / contract test (해당 시)
|
|
./gradlew :adapter-web:test --tests '*CleanArchitectureTest'
|
|
# 합격 기준: PASS 로그
|
|
|
|
# 3) 의도적 위반 빌드 깨기 (해당 시 — rule 검증)
|
|
# 임시로 위반 코드 추가 → 빌드 → 실패 확인 → 위반 코드 제거
|
|
```
|
|
|
|
**수동 self-check**:
|
|
|
|
- [ ] 위 자동 명령 모두 exit 0
|
|
- [ ] 의도적 위반 시 *정확히* 의도된 rule 이름이 실패 메시지에 포함됨
|
|
- [ ] L1~L3 학습 목표가 실제로 *할 수 있다* 상태인지 (1줄로 설명 가능)
|
|
- [ ] commit 메시지가 "왜" 를 답함 ("Add X" 가 아니라 "Enforce X to prevent Y")
|
|
|
|
## 7. 결과물
|
|
|
|
> 과제가 끝났을 때 남는 산출물. 휘발성 학습이 아니라 *재사용 가능한 흔적* 을 남긴다.
|
|
> 근거: `[[raw/company-tech-blogs/skillable-hands-on-lab-structure]]#SKILL-LAB-C1` — Outcomes 는 7-component spec 의 마지막 anchor.
|
|
|
|
- **commit / PR**:
|
|
- 브랜치: `daily-task/develop/{{slug}}`
|
|
- commits: <해시 + 1줄 메시지>
|
|
- PR URL (있다면):
|
|
- **신규/변경 파일**:
|
|
- `<path/to/file>` — <역할 한 줄>
|
|
- **학습한 개념** (wiki/concepts 로 ingest 후보):
|
|
- <개념 1> — `/ingest` 시점에 `wiki/concepts/<slug>` 로 추출 가능 여부 메모
|
|
- **다음 과제 thread** (실수·궁금증·심화 주제):
|
|
- <오늘 막혔던 지점에서 자연스럽게 파생되는 과제 후보 — 내일 또는 다음 주 daily-task 시드>
|
|
|
|
## 8. 회고
|
|
|
|
> 과제 끝난 직후 5분 회고. 빈칸으로 두지 말 것. 빈 회고 = 학습 손실.
|
|
> 근거: `[[raw/company-tech-blogs/deliberate-practice-software-developers-redgreencode]]#DP-RGC-C4` — "After you finish each problem, ask yourself if you can improve any aspect of your problem-solving process based on your experience with that problem."
|
|
|
|
- **막혔던 곳** (몇 분 / 어디서):
|
|
- **예상과 다른 점** (가정이 깨진 부분):
|
|
- **다음 반복에서 개선할 점** (방법론 / 도구 / 정보 수집 순서):
|
|
- **부수 효과로 발견한 것** (의도 외 학습):
|
|
- **이 과제의 난이도가 적정했는가** (`너무 쉬움` / `적정` / `너무 어려움` — frontmatter `difficulty` 조정 신호):
|
|
|
|
## 9. 출처
|
|
|
|
> 본 과제의 구조 근거 + 도메인 근거.
|
|
|
|
| Source | 정당화 영역 |
|
|
|---|---|
|
|
| `[[raw/company-tech-blogs/skillable-hands-on-lab-structure]]` | template 9-section 구조 자체 (§1, §2, §3, §6, §7) |
|
|
| `[[raw/company-tech-blogs/deliberate-practice-software-developers-redgreencode]]` | §5 단계 분할 + §6 objective 평가 + §8 reflection 원리 |
|
|
| `[[raw/official-docs/<...>]]` | 도메인 결정 근거 (Spring Boot / Java spec / Jackson 등) |
|
|
| `[[raw/branch-notes/<...>]]` | 본 과제가 검증하려는 branch 결정 |
|
|
|
|
## 10. 완료 후 정리
|
|
|
|
> done 으로 바뀌는 순간 채움. `/ingest` 가 이 섹션을 기준으로 wiki 영역으로 promotable 항목 추출.
|
|
|
|
- **최종 status_label**: `done` | `abandoned`
|
|
- **소요 시간 실측**: <분> (vs frontmatter `duration_estimate` <분>) — 차이 분석은 §8 회고에
|
|
- **promotable 후보**:
|
|
- `actually-implemented` → 어느 branch-note 의 어느 결정과 연결되는지
|
|
- `locally-verified` → 어떤 명령으로 검증됐는지
|
|
- **추출하지 않을 항목** (단순 학습 / 폐기):
|