docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links
This commit is contained in:
Antigravity Agent
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 효율적인 API 통신 패턴 (Axios & Interceptors)
|
||||
category: Software [[Architecture]]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [API, Axios, Interceptor, Error Handling, Network]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[API_Communication_Patterns]] (API 통신 패턴)
|
||||
# [[API_Communication_Patterns|API_Communication_Patterns]] (API 통신 패턴)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 서버와의 대화는 항상 '정중하되 의심하며' 처리하라. 모든 요청은 중앙 통제소(Interceptor)를 거치고 모든 에러는 시나리오가 준비되어 있어야 한다.
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- 모든 통신에 Axios가 정답은 아니다. 브라우저 네이티브인 `fetch`로도 충분한 경우가 많으며, 라이브러리 의존성을 낮추는 것이 가벼운 앱을 만드는 첫걸음일 수 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[System_Protocol_Standard]] , [[React_[[State]]_[[Management]]_Strategy]]
|
||||
- Foundation: [[Reliability_Safety_First]]
|
||||
- Related: [[System_Protocol_Standard|System_Protocol_Standard]] , React_State_Management_Strategy
|
||||
- Foundation: [[Reliability_Safety_First|Reliability_Safety_First]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, clean-architecture, design-patterns, mvc, separation-of-con
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Clean Architecture & Patterns]]
|
||||
# [[Clean Architecture & Patterns|Clean Architecture & Patterns]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "기술적 세부 사항(DB, Framework)으로부터 비즈니스 로직을 격리하여, 시스템의 수명을 연장하고 변화에 유연하게 대응하게 만드는 관심사 분리(Separation of Concerns)의 정점."
|
||||
@@ -27,9 +27,9 @@ last_reinforced: 2026-05-01
|
||||
- **아키텍처 부패 (Architectural Decay)**: 시간이 흐름에 따라 편의를 위해 계층을 우회하는 코드가 쌓일 수 있습니다. 매 PR마다 아키텍처 무결성을 점검하여 부패를 조기에 차단해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: 아키텍처를 지탱하는 세부 설계 원칙.
|
||||
- [[Architecture Review]]: 아키텍처 일관성을 검증하는 프로세스.
|
||||
- [[Dependency Management (DI & DIP)]]: 계층 간 결합도를 낮추는 기술적 수단.
|
||||
- [[Single Responsibility Principle (SRP)]]: 컴포넌트 분리의 근거.
|
||||
- [[Abstraction & Over-engineering]]: 아키텍처 도입 시 경계해야 할 함정.
|
||||
- [[SOLID Principles|SOLID Principles]]: 아키텍처를 지탱하는 세부 설계 원칙.
|
||||
- [[Architecture Review (아키텍처 및 설계 리뷰)|Architecture Review]]: 아키텍처 일관성을 검증하는 프로세스.
|
||||
- [[Dependency Management (DI & DIP)|Dependency Management (DI & DIP]]: 계층 간 결합도를 낮추는 기술적 수단.
|
||||
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 컴포넌트 분리의 근거.
|
||||
- Abstraction & Over-engineering: 아키텍처 도입 시 경계해야 할 함정.
|
||||
---
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, clean-architecture, layering, decoupling, domain-driven-des
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Clean Architecture]]
|
||||
# [[Clean Architecture|Clean Architecture]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "비즈니스 로직(Domain)을 중심에 두고 UI, DB, 프레임워크와 같은 외부 세부 사항을 주변부로 밀어내어, 외부 기술의 변화가 시스템의 핵심 논리에 영향을 주지 않도록 격리하는 계층화 아키텍처의 정수."
|
||||
@@ -31,9 +31,9 @@ last_reinforced: 2026-05-01
|
||||
- **학습 곡선**: 계층 간 경계를 엄격히 지키는 설계 철학을 팀 전체가 공유하고 준수하는 데 높은 수준의 컨센서스와 코드 리뷰 역량이 요구됩니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: 각 계층 내부 설계를 지탱하는 원칙들.
|
||||
- [[Domain-Driven Design (DDD)]]: 도메인 중심 설계 사상과의 시너지.
|
||||
- [[Dependency Inversion Principle (DIP)]]: 계층 간 통신을 가능하게 하는 핵심 기술.
|
||||
- [[Software Architecture Patterns]]: MVC, Hexagonal 아키텍처 등과의 비교.
|
||||
- [[Over-engineering]]: 패턴의 맹목적 적용 시 경계해야 할 부작용.
|
||||
- [[SOLID Principles|SOLID Principles]]: 각 계층 내부 설계를 지탱하는 원칙들.
|
||||
- [[Domain-Driven-Design-DDD|Domain-Driven Design (DDD]]: 도메인 중심 설계 사상과의 시너지.
|
||||
- [[의존성 역전 원칙 (Dependency Inversion Principle DIP)|Dependency Inversion Principle (DIP]]: 계층 간 통신을 가능하게 하는 핵심 기술.
|
||||
- [[Software-Architecture-Patterns|Software Architecture Patterns]]: MVC, Hexagonal 아키텍처 등과의 비교.
|
||||
- Over-engineering: 패턴의 맹목적 적용 시 경계해야 할 부작용.
|
||||
---
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
---
|
||||
title: 컴포넌트 설계 패턴 (Atomic & Composition)
|
||||
category: Software [[Architecture]]
|
||||
tags: [Design Pattern, [[Atomic Design]], Composition, Architecture]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Design Pattern, [[Atomic Design|Atomic Design]], Composition, Architecture]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Component_Design_Patterns]] (컴포넌트 설계 패턴)
|
||||
# [[Component_Design_Patterns|Component_Design_Patterns]] (컴포넌트 설계 패턴)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 컴포넌트는 작을수록 강하고, 단순할수록 재사용성이 극대화된다. 복잡한 컴포넌트는 여러 개의 작고 순수한(Pure) 컴포넌트로 해체하라.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **Container-Presenter 패턴**:
|
||||
- **Container**: 데이터([[State]], API)를 가져오고 관리하는 '머리'.
|
||||
- **Container**: 데이터([[State|State]], API)를 가져오고 관리하는 '머리'.
|
||||
- **Presenter**: 오직 Props만 받아 화면을 그리는 '몸통'. 스타일과 UI 구조에만 집중하여 테스트 가능성을 높인다.
|
||||
- **[[Compound Components]] (복합 컴포넌트)**:
|
||||
- **[[Compound Components|Compound Components]] (복합 컴포넌트)**:
|
||||
- `<Select><Option /></Select>` 처럼 부모와 자식이 상태를 공유하며 하나의 긴밀한 기능을 수행하는 패턴. 사용자가 UI 구조를 자유롭게 배치할 수 있게 유연성을 제공한다.
|
||||
- **Atomic Design (원자 중심 설계)**:
|
||||
- Atom(버튼, 입력창) $\rightarrow$ Molecule(검색바) $\rightarrow$ Organism(헤더) $\rightarrow$ Template $\rightarrow$ Page.
|
||||
@@ -24,5 +24,5 @@ created: 2026-04-20
|
||||
- 너무 과도한 컴포넌트 분할은 프로토타이핑 속도를 늦춘다. 처음에는 크게 짜고, 중복이 발생하거나 복잡도가 높아질 때 '사후적 리팩토링'을 통해 분리하는 것이 실무적으로 현명하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: Project_Architecture_Guidelines , [[Styling_Governance]]
|
||||
- Design: [[Accessibility_Inclusivity]]
|
||||
- Related: Project_Architecture_Guidelines , [[Styling_Governance|Styling_Governance]]
|
||||
- Design: [[Accessibility_Inclusivity|Accessibility_Inclusivity]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, di, dependency-injection, decoupling, inversion-of-control,
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Dependency Injection (DI)]]
|
||||
# [[Dependency Injection (DI)|Dependency Injection (DI]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "클래스 내부에서 직접 의존 객체를 생성하지 않고 외부에서 주입받음으로써, 객체 간의 결합을 끊어내고 테스트와 확장이 용이한 '유연한 부품'으로 만드는 제어 역전(IoC)의 실천적 기법."
|
||||
@@ -28,9 +28,9 @@ DI는 현대 소프트웨어 아키텍처에서 컴포넌트 간의 결합도를
|
||||
- **코드 추적성 저하**: 정적 코드만으로는 어떤 구현체가 주입될지 즉각 확인하기 어려울 수 있습니다. 이를 해결하기 위해 명확한 네이밍 컨벤션과 DI 바인딩 로그의 가시성 확보가 중요합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: 의존성 역전 원칙(DIP)의 실현 방법.
|
||||
- [[Single Responsibility Principle (SRP)]]: 클래스의 책임을 생성과 실행으로 분리하는 관점.
|
||||
- [[Testability]]: Mock 객체 주입을 통한 단위 테스트 용이성 확보.
|
||||
- [[Constructor Injection]]: 가장 권장되는 DI 패턴.
|
||||
- [[Dependency Lifetimes]]: Transient, Scoped, Singleton의 이해.
|
||||
- [[SOLID Principles|SOLID Principles]]: 의존성 역전 원칙(DIP)의 실현 방법.
|
||||
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 클래스의 책임을 생성과 실행으로 분리하는 관점.
|
||||
- [[테스트 용이성 (Testability)|Testability]]: Mock 객체 주입을 통한 단위 테스트 용이성 확보.
|
||||
- Constructor Injection: 가장 권장되는 DI 패턴.
|
||||
- Dependency Lifetimes: Transient, Scoped, Singleton의 이해.
|
||||
---
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, dependency-management, dependency-injection, di, dependency
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Dependency Management (DI & DIP)]]
|
||||
# [[Dependency Management (DI & DIP)|Dependency Management (DI & DIP]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "구체적인 구현이 아닌 추상화에 의존하게 하여 컴포넌트 간의 결합도를 낮추고, 코드 수정 없이 기능을 확장하거나 교체할 수 있는 유연한 시스템 구조의 핵심 기법."
|
||||
@@ -14,10 +14,10 @@ last_reinforced: 2026-05-01
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
의존성 관리는 소프트웨어의 모듈성과 테스트 가능성을 결정짓는 가장 중요한 설계 요소입니다.
|
||||
|
||||
1. **[[Dependency Inversion Principle (DIP)]]**:
|
||||
1. **[[의존성 역전 원칙 (Dependency Inversion Principle DIP)|Dependency Inversion Principle (DIP]]**:
|
||||
* **고수준 모듈의 보호**: 고수준 모듈(비즈니스 로직)은 저수준 모듈(데이터베이스, 외부 API)의 구체적인 구현에 의존해서는 안 됩니다. 둘 다 추상화(인터페이스)에 의존해야 합니다.
|
||||
* **의존성 방향의 역전**: 전통적인 계층 구조에서의 의존성 방향을 뒤집어, 구현체가 인터페이스를 따르게 함으로써 핵심 로직을 외부 변화로부터 보호합니다.
|
||||
2. **[[Dependency Injection (DI)]]**:
|
||||
2. **[[Dependency Injection (DI)|Dependency Injection (DI]]**:
|
||||
* **객체 생성이 아닌 주입**: 클래스 내부에서 의존 객체를 직접 생성(New)하지 않고, 외부(생성자, 메서드 등)에서 주입받습니다.
|
||||
* **유연한 교체**: 인터페이스를 통해 종속성을 주입받으므로, 실제 구현체를 환경(Staging, Production)이나 테스트 목적(Mocking)에 따라 쉽게 교체할 수 있습니다.
|
||||
3. **코드 리뷰에서의 역할**:
|
||||
@@ -28,9 +28,9 @@ last_reinforced: 2026-05-01
|
||||
- **의존성 그래프의 복잡성**: 주입되는 객체가 많아지면 객체 생성 로직이나 DI 컨테이너 설정이 복잡해집니다. 생성자 주입(Constructor Injection)을 권장하고 클래스의 책임을 작게 유지하여 주입되는 의존성 수를 제한해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: DIP가 포함된 설계 원칙 그룹.
|
||||
- [[Clean Architecture & Patterns]]: DIP를 통해 도메인 로직을 보호하는 상위 아키텍처.
|
||||
- [[Testing Strategy]]: DI가 가능하게 하는 테스트 용이성.
|
||||
- [[Single Responsibility Principle (SRP)]]: 의존성이 많아지는 것을 방지하는 근거.
|
||||
- [[Over-engineering]]: 무분별한 추상화의 위험.
|
||||
- [[SOLID Principles|SOLID Principles]]: DIP가 포함된 설계 원칙 그룹.
|
||||
- [[Clean Architecture & Patterns|Clean Architecture & Patterns]]: DIP를 통해 도메인 로직을 보호하는 상위 아키텍처.
|
||||
- [[Testing Strategy|Testing Strategy]]: DI가 가능하게 하는 테스트 용이성.
|
||||
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 의존성이 많아지는 것을 방지하는 근거.
|
||||
- Over-engineering: 무분별한 추상화의 위험.
|
||||
---
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Index: Topics > 02_Architecture_Principles
|
||||
|
||||
## 📝 Documents
|
||||
- [[API_Communication_Patterns]]
|
||||
- [[Component_Design_Patterns]]
|
||||
- [[Separation_of_Concerns]]
|
||||
- [[Single_Source_of_Truth]]
|
||||
- [[Systemic_Simulation_Principles]]
|
||||
- [[API_Communication_Patterns|API_Communication_Patterns]]
|
||||
- [[Component_Design_Patterns|Component_Design_Patterns]]
|
||||
- [[Separation_of_Concerns|Separation_of_Concerns]]
|
||||
- [[Single_Source_of_Truth|Single_Source_of_Truth]]
|
||||
- [[Systemic_Simulation_Principles|Systemic_Simulation_Principles]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, design-pattern, mvc, decoupling, ui-architecture, p-reinfor
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[MVC (Model-View-Controller)]]
|
||||
# [[MVC (Model-View-Controller)|MVC (Model-View-Controller]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터(Model), 사용자 인터페이스(View), 로직 제어(Controller)를 분리하여 시스템의 관심사를 격리함으로써, UI의 변화가 데이터 구조에 영향을 주지 않도록 설계하는 고전적이고 강력한 관심사 분리(SoC) 패턴."
|
||||
@@ -29,9 +29,9 @@ MVC는 애플리케이션의 구조적 무결성을 유지하기 위한 가장
|
||||
- **현대적 변형**: 웹 프레임워크의 발전에 따라 MVP, MVVM 등 다양한 변형 패턴이 등장하였으나, 관심사 분리라는 핵심 철학은 MVC에서 계승되었습니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Design Patterns]]: 아키텍처 패턴의 범주.
|
||||
- [[Clean Architecture]]: MVC를 보다 고도화한 계층화 구조.
|
||||
- [[SOLID Principles]]: 각 계층의 단일 책임을 정의하는 원칙.
|
||||
- [[Separation of Concerns (SoC)]]: 패턴의 근본적인 설계 철학.
|
||||
- [[Code Health]]: 일관된 패턴 준수가 가져오는 시스템의 건강성.
|
||||
- Design Patterns: 아키텍처 패턴의 범주.
|
||||
- [[Clean Architecture|Clean Architecture]]: MVC를 보다 고도화한 계층화 구조.
|
||||
- [[SOLID Principles|SOLID Principles]]: 각 계층의 단일 책임을 정의하는 원칙.
|
||||
- [[관심사의 분리 (Separation of Concerns SoC)|Separation of Concerns (SoC]]: 패턴의 근본적인 설계 철학.
|
||||
- Code Health: 일관된 패턴 준수가 가져오는 시스템의 건강성.
|
||||
---
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, ooad, solid-principles, maintainability, code-review, p-rei
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[SOLID Principles]]
|
||||
# [[SOLID Principles|SOLID Principles]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "소프트웨어의 유지보수성과 확장성을 보장하기 위한 5가지 핵심 설계 기둥: 인지적 부하를 낮추고, 변화에 유연하며, 결합도가 낮은 강건한 시스템을 구축하기 위한 객체지향 설계의 표준 지침."
|
||||
@@ -14,20 +14,20 @@ last_reinforced: 2026-05-01
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
SOLID 원칙은 코드 리뷰와 시스템 설계의 무결성을 평가하는 핵심 기준입니다.
|
||||
|
||||
1. **[[Single Responsibility Principle (SRP)]]**: 클래스나 함수는 단 하나의 변경 이유만을 가져야 합니다. 모듈화를 통해 가독성과 테스트 용이성을 극대화합니다.
|
||||
1. **[[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]**: 클래스나 함수는 단 하나의 변경 이유만을 가져야 합니다. 모듈화를 통해 가독성과 테스트 용이성을 극대화합니다.
|
||||
2. **Open-Closed Principle (OCP)**: 확장에는 열려 있고 수정에는 닫혀 있어야 합니다. 기존 코드를 건드리지 않고 새로운 기능을 추가할 수 있는 구조를 지향합니다.
|
||||
3. **Liskov Substitution Principle (LSP)**: 하위 타입은 언제나 상위 타입으로 교체 가능해야 합니다. 상속 구조에서의 행동 일관성을 보장합니다.
|
||||
4. **Interface Segregation Principle (ISP)**: 클라이언트가 사용하지 않는 메서드에 의존하도록 강요해서는 안 됩니다. 거대한 인터페이스보다 구체적이고 작은 인터페이스 여러 개가 낫습니다.
|
||||
5. **[[Dependency Inversion Principle (DIP)]]**: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다. 구체적인 구현이 아닌 추상화에 의존하여 결합도를 낮춥니다.
|
||||
5. **[[의존성 역전 원칙 (Dependency Inversion Principle DIP)|Dependency Inversion Principle (DIP]]**: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다. 구체적인 구현이 아닌 추상화에 의존하여 결합도를 낮춥니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **추상화의 비용**: 확장성을 위해 인터페이스와 추상화를 과도하게 도입할 경우, 코드의 직관성이 떨어지고 오버엔지니어링(Over-engineering)으로 이어질 수 있습니다. 현재의 요구사항과 미래의 유연성 사이의 실용적 타협(Trade-off)이 필수적입니다.
|
||||
- **실행 흐름 파악의 어려움**: DI(의존성 주입)를 극한으로 활용할 경우 런타임에 의존성이 결정되므로, 코드 정적 분석만으로는 전체 실행 흐름을 파악하기 어려워질 수 있습니다. 이를 보완하기 위한 명확한 문서화와 추적 로직이 필요합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Single Responsibility Principle (SRP)]]: 첫 번째 원칙의 심화.
|
||||
- [[Dependency Injection (DI)]]: DIP를 실현하는 구체적 기법.
|
||||
- [[Clean Architecture]]: SOLID를 애플리케이션 전체로 확장한 구조.
|
||||
- [[Abstraction & Over-engineering]]: 설계 시 경계해야 할 트레이드오프.
|
||||
- [[Test-Driven Development (TDD)]]: 테스트하기 좋은 코드를 만드는 원칙으로서의 연결.
|
||||
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 첫 번째 원칙의 심화.
|
||||
- [[Dependency Injection (DI)|Dependency Injection (DI]]: DIP를 실현하는 구체적 기법.
|
||||
- [[Clean Architecture|Clean Architecture]]: SOLID를 애플리케이션 전체로 확장한 구조.
|
||||
- Abstraction & Over-engineering: 설계 시 경계해야 할 트레이드오프.
|
||||
- Test-Driven Development (TDD: 테스트하기 좋은 코드를 만드는 원칙으로서의 연결.
|
||||
---
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 시스템 아키텍처와 관심사 분리 ([[Separation of Concerns]])
|
||||
category: Software [[Architecture]]
|
||||
title: 시스템 아키텍처와 관심사 분리 ([[_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]])
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Architecture, SoC, Modular Design, Design Pattern]
|
||||
created: 2026-04-20
|
||||
---
|
||||
@@ -11,8 +11,8 @@ created: 2026-04-20
|
||||
복잡한 소프트웨어 시스템을 역할별로 구분된 독립적인 모듈로 나누어, 유지보수성과 확장성을 극대화하는 설계 철학입니다.
|
||||
|
||||
## 🚀 계층구조 예시 (Layering Example)
|
||||
1. **[[Logic]] Engine**: 순수 비즈니스 로직 및 규칙 수행 (예: `gameWorker.js`)
|
||||
2. **[[State]] Manager**: 데이터의 중앙 집중 처리 (예: `TetrisGame.jsx`)
|
||||
1. **[[Logic|Logic]] Engine**: 순수 비즈니스 로직 및 규칙 수행 (예: `gameWorker.js`)
|
||||
2. **[[State|State]] Manager**: 데이터의 중앙 집중 처리 (예: `TetrisGame.jsx`)
|
||||
3. **View Layer**: 사용자 인터페이스 표현 및 렌더링 (예: React Components)
|
||||
|
||||
## 💡 레슨 런 (Lesson Learned)
|
||||
@@ -21,5 +21,5 @@ created: 2026-04-20
|
||||
> 기능을 추가할 때 기존 코드를 수정하기보다 새로운 모듈을 덧붙일 수 있는 구조를 고민해야 합니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[WebWorker_Performance]]
|
||||
- [[Single_Source_of_Truth]]
|
||||
- [[WebWorker_Performance|WebWorker_Performance]]
|
||||
- [[Single_Source_of_Truth|Single_Source_of_Truth]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture, srp, cohesion, refactoring, code-review, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Single Responsibility Principle (SRP)]]
|
||||
# [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "하나의 모듈은 오직 하나의 변경 이유(Reason to change)만을 가져야 한다: 코드의 응집도를 높이고 복잡성을 분산하여, 버그 수정과 기능 확장이 다른 영역에 미치는 부작용을 최소화하는 설계의 기초."
|
||||
@@ -28,9 +28,9 @@ SRP는 객체 지향 설계의 첫 번째 단추이자 가장 보편적인 리
|
||||
- **아키텍처적 부채**: 초기 설계 시 SRP를 무시하면 시간이 흐를수록 '신(God) 객체'가 탄생하며, 이는 리팩토링 비용을 기하급수적으로 증가시키는 주요 원인이 됩니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: 5대 원칙의 시작점.
|
||||
- [[Testability]]: 테스트하기 좋은 코드를 만드는 직접적 원인.
|
||||
- [[Refactoring]]: SRP 위반 시 리뷰어가 내리는 핵심 처방.
|
||||
- [[Clean Architecture]]: 책임을 계층별로 격리하는 거시적 구조.
|
||||
- [[Code Readability]]: 단순해진 코드가 가져오는 가독성 향상.
|
||||
- [[SOLID Principles|SOLID Principles]]: 5대 원칙의 시작점.
|
||||
- [[테스트 용이성 (Testability)|Testability]]: 테스트하기 좋은 코드를 만드는 직접적 원인.
|
||||
- [[Refactoring|Refactoring]]: SRP 위반 시 리뷰어가 내리는 핵심 처방.
|
||||
- [[Clean Architecture|Clean Architecture]]: 책임을 계층별로 격리하는 거시적 구조.
|
||||
- Code Readability: 단순해진 코드가 가져오는 가독성 향상.
|
||||
---
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 상태 관리의 단일 진실 공급원 ([[Single Source of Truth]])
|
||||
category: Software [[Architecture]]
|
||||
tags: [[[State]] [[Management]], Data Consistency, Redux, Architecture]
|
||||
title: 상태 관리의 단일 진실 공급원 ([[Single_Source_of_Truth|Single Source of Truth]])
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [[State|[State]] [[Management|Management]], Data Consistency, Redux, Architecture]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -10,7 +10,7 @@ created: 2026-04-20
|
||||
## 🎯 개요 (Overview)
|
||||
시스템의 핵심 데이터를 중앙 집중식으로 관리하여, 데이터 불일치(Inconsistency) 현상을 원천 차단하고 예측 가능한 데이터 흐름을 확보하는 설계 원칙입니다.
|
||||
|
||||
## 🚀 주요 원칙 (Key [[Principles]])
|
||||
## 🚀 주요 원칙 (Key [[Principles|Principles]])
|
||||
- **단일 지점 정의 (Defined at Single Point)**: 상태는 오직 한 곳에서만 정의되고 관리되어야 합니다.
|
||||
- **예측 가능성 (Predictability)**: 상태 변경은 정해진 규칙(Action/Setter)을 통해서만 발생하여 디버깅을 용이하게 합니다.
|
||||
|
||||
@@ -20,5 +20,5 @@ created: 2026-04-20
|
||||
> 코드의 파편화를 막기 위해 데이터의 책임 범위(Responsibility)를 명확히 하는 것이 대규모 프로젝트 성공의 열쇠입니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Separation_of_Concerns]]
|
||||
- [[Domain-Driven Design (DDD)]]
|
||||
- [[Separation_of_Concerns|Separation_of_Concerns]]
|
||||
- [[Domain-Driven-Design-DDD|Domain-Driven Design (DDD]]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 시스템 시뮬레이션 설계 원리
|
||||
category:[[ system]]ic Modeling & Fun
|
||||
tags: [Simulation, [[Physics]] Engine, Systemic Modeling, Ruleset]
|
||||
category:Systemic Modeling & Fun
|
||||
tags: [Simulation, [[Physics|Physics]] Engine, Systemic Modeling, Ruleset]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -20,5 +20,5 @@ created: 2026-04-20
|
||||
> 이를 통해 단순한 게임을 넘어 자율주행, 물리 엔진 등 고도의 결정론적 시스템 모델링이 가능해집니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[WebWorker_Performance]]
|
||||
- [[Separation_of_Concerns]]
|
||||
- [[WebWorker_Performance|WebWorker_Performance]]
|
||||
- [[Separation_of_Concerns|Separation_of_Concerns]]
|
||||
|
||||
Reference in New Issue
Block a user