Antigravity Agent
60 lines
3.9 KiB
Markdown
60 lines
3.9 KiB
Markdown
## 📌 Brief Summary
|
|
Clean Code와 SOLID 원칙은 유지보수성, 가독성, 확장성을 확보하기 위한 소프트웨어 공학의 핵심 설계 지침이다. 현대의 React 생태계에서 이러한 원칙들은 비즈니스 로직과 UI의 결합도를 낮추고, 예측 가능한 컴포넌트 아키텍처를 구축하며, 기술 부채 누적을 방지하는 기반 역할을 한다.
|
|
|
|
## 📖 Core Content
|
|
1. **SOLID Principles in React**
|
|
- **SRP (단일 책임)**: 컴포넌트나 훅은 하나의 명확한 목적만 가져야 한다 (300줄 기준).
|
|
- **OCP (개방-폐쇄)**: 코드 수정 대신 컴포넌트 합성(Composition)을 통해 기능을 확장한다.
|
|
- **ISP (인터페이스 분리)**: 필요한 Props만 전달하여 컴포넌트 간 불필요한 결합을 차단한다.
|
|
- **DIP (의존성 역전)**: 구체적 구현이 아닌 추상화(Context, Props)에 의존하여 주입받는다.
|
|
2. **Clean Code & 핵심 원칙**
|
|
- **DRY (중복 제거)**: 커스텀 훅으로 공통 로직을 추출하되, 과도한 추상화는 경계한다.
|
|
- **KISS (단순성 유지)**: 복잡한 로직보다 직관적이고 단순한 코드를 우선시한다.
|
|
- **YAGNI (불필요 기능 배제)**: 당장 필요하지 않은 미래의 확장성을 미리 구현하지 않는다.
|
|
3. **실무적 가이드라인**
|
|
- 명확한 네이밍(PascalCase, camelCase)과 낮은 중첩 구조를 유지한다.
|
|
- 동일 패턴이 3번 이상 반복될 때(`Rule of Three`) 비로소 추상화를 진행하여 섣부른 최적화를 방지한다.
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
- **추상화 vs 단순함**: DRY 원칙을 지키려다 만든 고차원적인 추상화가 오히려 코드의 흐름을 파악하기 어렵게 만들어 KISS 원칙을 위반할 수 있다.
|
|
- **초기 개발 속도**: 엄격한 원칙 준수는 초기 보일러플레이트와 설계 시간을 증가시키나, 장기적인 유지보수 비용을 획기적으로 줄여준다.
|
|
- **오버엔지니어링의 위험**: YAGNI를 무시하고 설계한 '미래 대비용' 코드는 결국 사용되지 않는 'Dead Code'가 되어 시스템의 짐이 될 가능성이 높다.
|
|
|
|
## 🔗 Knowledge Connections
|
|
### Related Concepts (Auto-Linked)
|
|
* [[Custom_Hooks]]
|
|
* [[ESLint]]
|
|
* [[Engineering_Principles]]
|
|
* [[Feature-Sliced_Design]]
|
|
* [[Inversion]]
|
|
* [[Principles]]
|
|
* [[React]]
|
|
* [[Refactoring]]
|
|
* [[Refactoring Techniques]]
|
|
* [[Research]]
|
|
* [[Rule of Three]]
|
|
* [[SOLID_Principles]]
|
|
* [[Software Engineering Principles]]
|
|
* [[SonarQube]]
|
|
|
|
### Related Concepts
|
|
- **Component Composition**: OCP 실현의 핵심 (관계: 구현 패턴)
|
|
- **Custom Hooks**: DRY 및 SRP를 위한 물리적 단위 (관계: 실천 도구)
|
|
- **Feature-Sliced Design (FSD)**: 원칙의 구조적 강제 (관계: 아키텍처 프레임워크)
|
|
|
|
### Deeper Research Questions
|
|
1. 함수형 React 환경에서 상속 없이 리스코프 치환 원칙(LSP)을 준수하는 인터페이스 설계 전략은?
|
|
2. 섣부른 추상화(Premature Abstraction)가 전체 프로젝트의 인지 부하와 유지보수 비용에 미치는 정량적 영향은?
|
|
3. DIP(의존성 역전)를 위해 Context를 남발할 때 발생하는 성능 저하와 이를 방지하기 위한 'Inversion of Control' 패턴의 조화는?
|
|
4. Clean Code를 강제하기 위한 정적 분석 도구(ESLint, SonarQube)의 규칙을 팀의 기술적 성숙도에 따라 어떻게 커스터마이징하는가?
|
|
5. YAGNI 원칙 하에서 '나중에 고치기 쉬운 코드'를 작성하기 위한 아키텍처적 유연성(Flexibility)의 최소 단위는?
|
|
|
|
### Practical Application Contexts
|
|
- **코드 리뷰 기준 수립**: 팀 전체의 코드 품질 상향 평준화를 위한 명확한 체크리스트 제공.
|
|
- **대규모 리팩토링 가이드**: 복잡하게 얽힌 레거시 코드를 단일 책임 원칙에 따라 분해하고 정돈.
|
|
|
|
### Adjacent Topics
|
|
- **Software Engineering Principles**
|
|
- **Refactoring Techniques**
|
|
- **Test Driven Development (TDD)**
|