[P-Reinforce] Wikify Legacy Migration, Core Agent Protocols, Engineering Principles, and Git Workflows
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,45 @@
|
||||
---
|
||||
id: a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
confidence_score: 0.99
|
||||
tags: [engineering-principles, solid, dry, kiss, yagni, clean-code, software-engineering]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-engineering-principles"
|
||||
---
|
||||
|
||||
# [[Engineering Principles (SOLID, DRY, KISS, YAGNI)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 소프트웨어 엔지니어링의 핵심 원칙들은 코드의 복잡성을 통제하고 유지보수성을 극대화하기 위한 도구이며, 특히 SOLID와 DRY/KISS/YAGNI는 '단순함'과 '유연함' 사이의 최적의 균형점을 찾기 위한 지침이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. SOLID 원칙 (Object-Oriented Design)
|
||||
- **SRP (단일 책임 원칙)**: 하나의 모듈/컴포넌트는 오직 하나의 책임(변경 이유)만 가져야 한다. React에서는 거대한 컴포넌트를 기능별로 쪼개는 핵심 근거가 된다.
|
||||
- **OCP (개방-폐쇄 원칙)**: 확장에는 열려 있고 수정에는 닫혀 있어야 한다. 컴포넌트 합성을 통해 기존 코드를 건드리지 않고 기능을 확장한다.
|
||||
- **LSP (리스코프 치환 원칙)**: 자식 클래스(또는 서브 컴포넌트)는 부모의 역할을 온전히 수행할 수 있어야 한다.
|
||||
- **ISP (인터페이스 분리 원칙)**: 사용하지 않는 인터페이스(Props)에 의존하지 않도록 잘게 쪼갠다.
|
||||
- **DIP (의존성 역전 원칙)**: 구체적인 구현이 아닌 추상화에 의존하여 결합도를 낮춘다.
|
||||
|
||||
### 2. Pragmatic Principles (DRY, KISS, YAGNI)
|
||||
- **DRY (Don't Repeat Yourself)**: 지식의 중복을 피한다. 반복되는 로직은 커스텀 훅이나 유틸리티로 추출한다.
|
||||
- **KISS (Keep It Simple, Stupid)**: 단순함이 궁극의 정교함이다. 과도한 추상화보다 직관적인 코드를 우선한다.
|
||||
- **YAGNI (You Aren't Gonna Need It)**: 실제로 필요하기 전까지는 기능을 미리 구현하지 않는다. 미래를 대비한 오버엔지니어링을 경계한다.
|
||||
|
||||
### 3. Clean Code 실무
|
||||
- **가독성 우선**: 코드는 컴퓨터가 읽기 위함이 아니라 사람이 읽기 위해 작성된다. 명확한 변수명과 함수 크기 조절이 필수적이다.
|
||||
- **단위 테스트 가능성**: 원칙을 준수한 코드는 자연스럽게 테스트하기 쉬운(Testable) 구조가 된다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **DRY vs KISS**: 중복을 제거하기 위한 무리한 추상화는 코드를 더 이해하기 어렵게 만든다. '세 번 반복될 때까지 기다리기(Rule of Three)'가 좋은 절충안이다.
|
||||
- **YAGNI vs 확장성**: 미래를 무시하는 것과 유연한 구조를 설계하는 것은 다르다. YAGNI는 '기능'에 대한 것이고, SOLID는 '구조'에 대한 것이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Legacy React Migration & Refactoring Standard]], [[Custom Hooks]], [[Feature-Sliced Design]]
|
||||
- **Raw Source**: [[00_Raw/DRY]], [[00_Raw/KISS]], [[00_Raw/YAGNI]], [[00_Raw/Single Responsibility Principle]], [[00_Raw/Clean Code and SOLID Principles]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Core Engineering Principles (SOLID, DRY, KISS, YAGNI)"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
id: b2c3d4e5-f6a7-4b8c-9d0e-1f2a3b4c5d6e
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
confidence_score: 0.98
|
||||
tags: [git, workflow, branching, github-flow, git-flow, trunk-based-development, devops]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-git-workflow"
|
||||
---
|
||||
|
||||
# [[Modern Git Workflows & Branching Strategies]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 효율적인 Git 워크플로우는 팀의 규모와 릴리즈 주기에 맞춰 선택되어야 하며, Trunk-based Development와 짧은 생명주기의 Feature Branch를 통해 지속적 통합(CI)의 가치를 실현하는 데 목적이 있다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 주요 전략별 특징
|
||||
- **Git Flow**: 정기적인 릴리즈 주기가 있는 대규모 프로젝트에 적합. `master`, `develop`, `feature`, `release`, `hotfix` 브랜치를 엄격히 관리한다.
|
||||
- **GitHub Flow**: 지속적 배포(CD)에 최적화된 단순한 모델. `main` 브랜치와 짧은 수명의 `feature` 브랜치만 사용하며, PR을 통해 상시 배포한다.
|
||||
- **Trunk-based Development**: 모든 개발자가 하루에도 여러 번 `main`에 직접 병합하는 방식. 충돌을 최소화하고 피드백 루프를 극대화한다.
|
||||
|
||||
### 2. 협업 및 품질 관리
|
||||
- **Pull Request (PR)**: 코드 리뷰를 위한 필수 관문. 변경 사항의 의도를 설명하고 자동화된 테스트를 통과해야 병합된다.
|
||||
- **Conventional Commits**: `feat:`, `fix:`, `refactor:` 등 규격화된 접두사를 사용하여 커밋 메시지의 가독성을 높이고 릴리즈 노트를 자동화한다.
|
||||
- **Atomic Commits**: 하나의 커밋은 하나의 논리적 변경만 담아야 한다. 이는 롤백과 디버깅(bisect)을 용이하게 한다.
|
||||
|
||||
### 3. 프론트엔드 팀을 위한 전략
|
||||
- **짧은 생명주기**: 브랜치가 며칠씩 유지되는 것을 지양하고, 가능한 빠르게 `main`에 통합하여 'Merge Hell'을 방지한다.
|
||||
- **Feature Flags**: 대규모 기능을 개발할 때 코드는 병합하되 런타임에 기능을 비활성화하여 Trunk-based 방식을 지원한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **복잡도 vs 제어**: Git Flow는 안전하지만 브랜치 관리 비용이 크며, GitHub Flow는 빠르지만 대규모 팀의 릴리즈 관리가 난해할 수 있다.
|
||||
- **Merge vs Rebase**: Rebase는 깨끗한 히스토리를 제공하지만 강제 푸시(force push) 위험이 있고, Merge는 보수적이지만 히스토리가 복잡해질 수 있다. 팀의 컨벤션 합의가 중요하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Engineering Principles (SOLID, DRY, KISS, YAGNI)]], [[CI-CD Pipeline Integration]]
|
||||
- **Raw Source**: [[00_Raw/Git Flow]], [[00_Raw/Git Workflow]], [[00_Raw/GitHub Flow]], [[00_Raw/Branching Strategies]], [[00_Raw/Trunk-based Development]], [[00_Raw/Atomic Commits]], [[00_Raw/Pull Request (PR)]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Modern Git Workflows and Branching Strategies"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
id: 7f8e9d2c-b1a3-4e5f-a0b2-c1d2e3f4a5b6
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
confidence_score: 0.98
|
||||
tags: [react, legacy, migration, refactoring, incremental-migration, architecture, frontend]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-legacy-react"
|
||||
---
|
||||
|
||||
# [[Legacy React Migration & Refactoring Standard]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 레거시 React 코드베이스의 현대화는 '전면 재작성(Rewrite)'이 아닌 '점진적 리팩토링(Incremental Refactor)'을 원칙으로 하며, 테스트 안전망 구축, 커스텀 훅을 통한 로직 분리, 그리고 FSD 아키텍처 도입을 통해 기술 부채를 체계적으로 해결하는 과정이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 리팩토링의 황금률: Refactor, Do Not Rewrite
|
||||
- **안전망 선구축**: 코드 수정 전 유닛 테스트 및 시각적 회귀 테스트(Storybook, Chromatic 등)를 통해 기존 기능의 무결성을 보장한다.
|
||||
- **점진적 마이그레이션**: 시스템 전체를 한 번에 바꾸는 대신, 알림이나 작은 기능 단위의 스토어부터 하나씩 최신 상태(Zustand, TanStack Query 등)로 전환한다.
|
||||
|
||||
### 2. 컴포넌트 및 언어의 현대화
|
||||
- **함수형 전환**: 클래스형 컴포넌트를 함수형 컴포넌트와 훅(Hooks) 기반으로 전환하며, 불필요한 `useEffect` 안티패턴을 제거한다.
|
||||
- **TypeScript 도입**: 정적 타이핑을 통해 코드의 예측 가능성을 높이며, 파일 단위로 점진적으로 적용한다.
|
||||
- **관심사 분리**: 비대한 컴포넌트(300줄 이상)에서 비즈니스 로직을 **커스텀 훅**으로 추출하여 UI와 로직을 분리한다.
|
||||
|
||||
### 3. 상태 관리 및 아키텍처 개편
|
||||
- **상태 분할**: 서버 데이터(TanStack Query), 전역 클라이언트 상태(Zustand), URL 상태 등으로 목적에 맞게 파편화하여 관리한다.
|
||||
- **FSD 아키텍처 도입**: 기술적 파일 유형(Type-based) 구조에서 비즈니스 도메인 중심의 **Feature-Sliced Design**으로 개편하여 모듈 간 결합도를 낮추고 응집도를 높인다.
|
||||
|
||||
### 4. 코드 거버넌스 및 표준화
|
||||
- **네이밍 규칙**: `kebab-case`(파일명/폴더명), `PascalCase`(컴포넌트), `camelCase`(훅/변수) 등 운영체제 및 팀 협업 표준을 수립한다.
|
||||
- **자동화**: ESLint, Prettier, Husky를 활용하여 커밋 시점에 아키텍처 경계 위반 및 포맷팅을 자동으로 검사한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **추상화의 함정 (DRY vs KISS)**: 중복 제거를 위한 과도한 추상화는 오히려 코드를 블랙박스화하여 디버깅을 어렵게 한다. '세 번 반복될 때까지 기다리기(Rule of Three)' 원칙을 준수해야 한다.
|
||||
- **과도기적 복잡성**: 점진적 마이그레이션 중에는 레거시와 신규 상태 관리 시스템이 공존하여 일시적으로 구조가 복잡해질 수 있음을 인지하고 마이그레이션 로드맵을 명확히 해야 한다.
|
||||
- **초기 오버헤드**: FSD 등의 엄격한 구조는 소규모 프로젝트에서는 과도한 설계(Overkill)가 될 수 있으므로 프로젝트 규모에 맞춰 유연하게 적용한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Feature-Sliced Design]], [[TanStack Query]], [[Zustand]], [[Unit Testing]], [[SOLID Principles]]
|
||||
- **Raw Source**: [[00_Raw/레거시 React 코드베이스 마이그레이션]], [[00_Raw/Incremental Migration]], [[00_Raw/Legacy React Codebase Modernization]], [[00_Raw/Legacy React Codebase Refactoring]], [[00_Raw/React Codebase Refactoring]], [[00_Raw/프론트엔드 리팩토링 및 코드 유지보수]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Legacy React Migration & Refactoring Standard"`
|
||||
3. Push: `git push origin main`
|
||||
Reference in New Issue
Block a user