Size: 5162
Comment:
|
Size: 11331
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 23: | Line 23: |
* UseDataToMakeLogicSimple - 로직과 데이터 구성 분리, DSL 활용 * ProblemSpaceSolutionSpace - 문제 영역과 해결 영역 구분 * MakeItWorkThenMakeBetter - 작동 우선, 개선은 나중에 * CraftNotScience - 프로그래밍은 과학이 아닌 기예 * Last5PercentAutomation - 마지막 5% 자동화의 함정 |
* '''DataAsFoundation''' - Separate data construction from business logic to achieve simplicity; create domain-specific languages when data structures become complex. The foundation of all clean code starts with well-organized data. ''Related: LanguageBuilding, ComplexityTaming'' * '''TwoWorlds''' - Distinguish clearly between the problem space (what needs to be solved) and solution space (how to implement it). Many programming errors stem from mixing these concerns too early in the thinking process. ''Related: StrongCenter, PatternHunting'' * '''WorkingFirst''' - Get something working before making it elegant or efficient. A working solution reveals the true nature of the problem and guides better design decisions. ''Related: BabySteps, OrganicGrowth'' * '''ArtisanMind''' - Approach programming as a craft requiring intuition, experience, and feel rather than pure systematic methodology. The best programmers combine technical knowledge with artistic sensibility. ''Related: MasterApprentice, NamesAsDesign'' * '''The95PercentRule''' - Resist the temptation to automate the final 5% of any process. That remaining complexity often costs more than the manual effort it would save. ''Related: WorkingFirst, ShortLeash'' |
Line 30: | Line 34: |
* '''[[TinyExperiment]]''' ✓ - 최소 실험을 통한 빠른 검증 * BabyStep - 작은 단계로 진행하기 * QuicklyStepBackToGreen - 빨간 막대 보면 가장 가까운 초록으로 * TDDIsDesignActivity - TDD는 설계 활동 * ShortFeedbackCycle - 짧은 피드백 루프 * MicroCommit - 한 번에 하나씩 마이크로 커밋 * Isolation - 격리 * UseAbduction - 추론 활용 * PiecemealGrowth - 점진적 성장, 중심부터 * CenterFirst - 핵심부터 시작 |
* '''[[TinyExperiment]]''' ✓ - Start with the smallest possible experiment that can teach you something meaningful about the problem. Each experiment should be so small that failure costs almost nothing. ''Related: BabySteps, GreenRefuge'' * '''BabySteps''' - Take the smallest possible step that moves toward your goal while maintaining system integrity. Large steps hide complexity and make debugging exponentially harder. ''Related: TinyExperiment, AtomicCommit'' * '''GreenRefuge''' - When tests fail, immediately return to the last known working state rather than trying to fix forward. Your green bar is a safe harbor in the storm of complexity. ''Related: SafetyNet, PresentMoment'' * '''DesignThroughTest''' - Use test-driven development as a design activity, not just a verification tool. The act of writing tests first reveals better API designs and cleaner interfaces. ''Related: CleanIsolation, TightLoop'' * '''TightLoop''' - Minimize the time between making a change and seeing its effect. Long feedback cycles allow errors to compound and make root causes harder to identify. ''Related: AtomicCommit, PresentMoment'' * '''AtomicCommit''' - Make each commit represent one complete, coherent change that can stand alone. Atomic commits make it easier to understand, review, and revert changes. ''Related: BabySteps, TightLoop'' * '''CleanIsolation''' - Design tests and modules so they can run independently without hidden dependencies. Isolation makes systems easier to understand, test, and modify. ''Related: DesignThroughTest, DirectPath'' * '''DetectiveWork''' - Use abductive reasoning to form hypotheses about what might be causing observed behavior. Good programmers are detectives who gather evidence before drawing conclusions. ''Related: RootHunting, PresentMoment'' * '''OrganicGrowth''' - Grow your system incrementally from a working core rather than building all parts simultaneously. Like biological growth, software grows healthiest when it maintains wholeness at each stage. ''Related: StrongCenter, WorkingFirst'' * '''StrongCenter''' - Start building from the most essential core functionality and grow outward. A strong center provides stability and coherence as the system expands. ''Related: OrganicGrowth, TwoWorlds'' |
Line 42: | Line 55: |
* EliminateIntermediateLayers - 중간 레이어 제거/축소 * OneAtATime - 한 가지씩 차례로 * DoNotGuessFar - 멀리 추측하지 말고 검증하기 * RegressionTest - 회귀 테스트 * HereAndNow - 지금 여기서 상황 파악하고 근본 원인 찾기 * FindRootCause - 웹 페이지 뒤지지 말고 근본 원인 찾기 |
* '''DirectPath''' - Eliminate unnecessary layers and indirection that obscure the flow from input to output. The shortest path between problem and solution is usually the clearest. ''Related: CleanIsolation, SingleFocus'' * '''SingleFocus''' - Work on exactly one thing at a time, completing it fully before moving to the next. Multitasking in debugging leads to confusion and missed connections. ''Related: AtomicCommit, PresentMoment'' * '''ShortLeash''' - When forming hypotheses about bugs or behavior, test them quickly rather than reasoning too far ahead. Long chains of reasoning multiply uncertainty and waste time. ''Related: DetectiveWork, TinyExperiment'' * '''SafetyNet''' - Build regression tests that catch previously fixed bugs if they reoccur. A good safety net lets you refactor and improve with confidence. ''Related: GreenRefuge, CleanIsolation'' * '''PresentMoment''' - Focus on understanding what is actually happening right now rather than what you think should be happening. The present moment contains all the information needed to solve most problems. ''Related: DetectiveWork, RootHunting'' * '''RootHunting''' - Dig systematically to find the actual cause rather than applying surface fixes or searching randomly. True root causes, once found, often reveal simple solutions. ''Related: PresentMoment, DetectiveWork'' |
Line 50: | Line 68: |
* FindProgrammingPattern - 프로그래밍 패턴 찾기 * DealWithComplexity - 복잡성을 이해하고 처리할 수 있는 도구들 * NamingIsDesign - 네이밍 자체가 설계 실천 * BuildLanguageSystem - 프로그래밍은 언어 시스템 구축 * MakeVocabulary - 어휘 만들기 |
* '''PatternHunting''' - Actively look for recurring structures and solutions in your code and others'. Recognizing patterns is the foundation of all programming expertise. ''Related: LanguageBuilding, MasterApprentice'' * '''ComplexityTaming''' - Develop a toolkit of techniques for managing complexity: abstraction, decomposition, naming, and separation of concerns. Complexity is the enemy of maintainability. ''Related: DataAsFoundation, DirectPath'' * '''NamesAsDesign''' - Treat naming as a design activity that clarifies thinking and reveals abstractions. Good names make code self-documenting and express intent clearly. ''Related: LanguageBuilding, ArtisanMind'' * '''LanguageBuilding''' - Approach programming as building a domain-specific language that perfectly expresses your problem space. The best programs read like well-written prose in a specialized vocabulary. ''Related: DataAsFoundation, LivingVocabulary'' * '''LivingVocabulary''' - Continuously evolve and refine the vocabulary used in your codebase as understanding deepens. Good vocabulary grows organically and adapts to new insights. ''Related: NamesAsDesign, OrganicGrowth'' |
Line 57: | Line 79: |
* ConsiderXP - 스크럼보다 익스트림 프로그래밍 고려 * PairProgramming - 다른 주니어들과 함께 뛰어난 성과 * PullRequestAntiPattern - PR 안티패턴 피하기 * YesButYesAnd - "네, 하지만" vs "네, 그리고" |
* '''TechnicalCommunity''' - Choose development practices that emphasize technical excellence and continuous learning over process compliance. Strong technical practices create better collaboration than rigid processes. ''Related: SharedMind, MasterApprentice'' * '''SharedMind''' - Work closely with other developers to combine knowledge and catch each other's blind spots. Two minds working together often produce insights neither could reach alone. ''Related: TechnicalCommunity, BuildingBridge'' * '''FlowingFeedback''' - Structure code reviews and feedback to maintain development flow rather than creating bottlenecks. Feedback should accelerate learning, not slow down progress. ''Related: BuildingBridge, TightLoop'' * '''BuildingBridge''' - Respond to ideas with "Yes, and..." rather than "Yes, but..." to build on others' contributions. Constructive dialogue creates better solutions than defensive reactions. ''Related: SharedMind, FlowingFeedback'' |
Line 63: | Line 88: |
* LearnFromExperts - 전문가로부터 잘 배우기 (CTA, CDE) * ApprenticeshipPattern - 견습 패턴 * ReflectivePractice - 성찰적 실천 * ReflectionInAction - 행동 중 성찰 * RecognitionPrimedDecision - 인식 우선 의사결정 |
* '''MasterApprentice''' - Learn directly from experts through observation, imitation, and guided practice. The master-apprentice relationship transfers tacit knowledge that books cannot convey. ''Related: CraftPath, ArtisanMind'' * '''CraftPath''' - Follow a deliberate progression from novice to expert, focusing on fundamentals before advanced techniques. Mastery requires patient development of core skills. ''Related: MasterApprentice, ThinkingMirror'' * '''ThinkingMirror''' - Regularly reflect on your thinking processes and decision-making patterns. Self-awareness about how you think improves both learning and problem-solving. ''Related: ActiveReflection, InstinctiveChoice'' * '''ActiveReflection''' - Think consciously about your actions and decisions while performing them, not just afterward. Real-time reflection improves performance and builds expertise faster. ''Related: ThinkingMirror, PresentMoment'' * '''InstinctiveChoice''' - Develop pattern recognition that allows rapid decision-making based on experienced intuition. Expert programmers often know the right answer before they can explain why. ''Related: PatternHunting, ArtisanMind'' |
Line 76: | Line 105: |
* UseDataToMakeLogicSimple - 로직 단순화의 핵심 * ProblemSpaceSolutionSpace - 사고 체계의 기본 |
* DataAsFoundation - 로직 단순화의 핵심 * TwoWorlds - 사고 체계의 기본 |
Line 80: | Line 109: |
* MakeItWorkThenMakeBetter, CraftNotScience, Last5PercentAutomation | * WorkingFirst, ArtisanMind, The95PercentRule |
Line 99: | Line 128: |
* UseDataToMakeLogicSimple 패턴 작성 시작 * ProblemSpaceSolutionSpace 구조 설계 |
* DataAsFoundation 패턴 작성 시작 * TwoWorlds 구조 설계 |
AiGarden/ToJuniorsPatternLanguage
주니어 개발자들을 위한 프로그래밍 피드백을 Christopher Alexander의 패턴 언어로 변환하는 프로젝트.
Contents
Project Vision
기술문서모음/ToJuniors 문서의 패턴들을 Alexander의 패턴 언어 형식으로 변환하여 구조적이고 교육적인 자료로 발전시키는 것이 목표입니다.
Core Principles
Structure-Preserving Baby Steps - 기존 구조를 보존하며 점진적 발전
Story-First Approach - 스토리로 시작해서 패턴으로 추상화
Educational Focus - 학습자 중심의 명확한 설명
Pattern Language Structure - Alexander 방식의 체계적 연결
Pattern Inventory
Foundation Patterns
Core Programming Principles
DataAsFoundation - Separate data construction from business logic to achieve simplicity; create domain-specific languages when data structures become complex. The foundation of all clean code starts with well-organized data. Related: LanguageBuilding, ComplexityTaming
TwoWorlds - Distinguish clearly between the problem space (what needs to be solved) and solution space (how to implement it). Many programming errors stem from mixing these concerns too early in the thinking process. Related: StrongCenter, PatternHunting
WorkingFirst - Get something working before making it elegant or efficient. A working solution reveals the true nature of the problem and guides better design decisions. Related: BabySteps, OrganicGrowth
ArtisanMind - Approach programming as a craft requiring intuition, experience, and feel rather than pure systematic methodology. The best programmers combine technical knowledge with artistic sensibility. Related: MasterApprentice, NamesAsDesign
The95PercentRule - Resist the temptation to automate the final 5% of any process. That remaining complexity often costs more than the manual effort it would save. Related: WorkingFirst, ShortLeash
TDD & Evolutionary Design Patterns
TinyExperiment ✓ - Start with the smallest possible experiment that can teach you something meaningful about the problem. Each experiment should be so small that failure costs almost nothing. Related: BabySteps, GreenRefuge
BabySteps - Take the smallest possible step that moves toward your goal while maintaining system integrity. Large steps hide complexity and make debugging exponentially harder. Related: TinyExperiment, AtomicCommit
GreenRefuge - When tests fail, immediately return to the last known working state rather than trying to fix forward. Your green bar is a safe harbor in the storm of complexity. Related: SafetyNet, PresentMoment
DesignThroughTest - Use test-driven development as a design activity, not just a verification tool. The act of writing tests first reveals better API designs and cleaner interfaces. Related: CleanIsolation, TightLoop
TightLoop - Minimize the time between making a change and seeing its effect. Long feedback cycles allow errors to compound and make root causes harder to identify. Related: AtomicCommit, PresentMoment
AtomicCommit - Make each commit represent one complete, coherent change that can stand alone. Atomic commits make it easier to understand, review, and revert changes. Related: BabySteps, TightLoop
CleanIsolation - Design tests and modules so they can run independently without hidden dependencies. Isolation makes systems easier to understand, test, and modify. Related: DesignThroughTest, DirectPath
DetectiveWork - Use abductive reasoning to form hypotheses about what might be causing observed behavior. Good programmers are detectives who gather evidence before drawing conclusions. Related: RootHunting, PresentMoment
OrganicGrowth - Grow your system incrementally from a working core rather than building all parts simultaneously. Like biological growth, software grows healthiest when it maintains wholeness at each stage. Related: StrongCenter, WorkingFirst
StrongCenter - Start building from the most essential core functionality and grow outward. A strong center provides stability and coherence as the system expands. Related: OrganicGrowth, TwoWorlds
Testing & Debugging Patterns
DirectPath - Eliminate unnecessary layers and indirection that obscure the flow from input to output. The shortest path between problem and solution is usually the clearest. Related: CleanIsolation, SingleFocus
SingleFocus - Work on exactly one thing at a time, completing it fully before moving to the next. Multitasking in debugging leads to confusion and missed connections. Related: AtomicCommit, PresentMoment
ShortLeash - When forming hypotheses about bugs or behavior, test them quickly rather than reasoning too far ahead. Long chains of reasoning multiply uncertainty and waste time. Related: DetectiveWork, TinyExperiment
SafetyNet - Build regression tests that catch previously fixed bugs if they reoccur. A good safety net lets you refactor and improve with confidence. Related: GreenRefuge, CleanIsolation
PresentMoment - Focus on understanding what is actually happening right now rather than what you think should be happening. The present moment contains all the information needed to solve most problems. Related: DetectiveWork, RootHunting
RootHunting - Dig systematically to find the actual cause rather than applying surface fixes or searching randomly. True root causes, once found, often reveal simple solutions. Related: PresentMoment, DetectiveWork
Programming Fundamentals
PatternHunting - Actively look for recurring structures and solutions in your code and others'. Recognizing patterns is the foundation of all programming expertise. Related: LanguageBuilding, MasterApprentice
ComplexityTaming - Develop a toolkit of techniques for managing complexity: abstraction, decomposition, naming, and separation of concerns. Complexity is the enemy of maintainability. Related: DataAsFoundation, DirectPath
NamesAsDesign - Treat naming as a design activity that clarifies thinking and reveals abstractions. Good names make code self-documenting and express intent clearly. Related: LanguageBuilding, ArtisanMind
LanguageBuilding - Approach programming as building a domain-specific language that perfectly expresses your problem space. The best programs read like well-written prose in a specialized vocabulary. Related: DataAsFoundation, LivingVocabulary
LivingVocabulary - Continuously evolve and refine the vocabulary used in your codebase as understanding deepens. Good vocabulary grows organically and adapts to new insights. Related: NamesAsDesign, OrganicGrowth
Collaboration Patterns
TechnicalCommunity - Choose development practices that emphasize technical excellence and continuous learning over process compliance. Strong technical practices create better collaboration than rigid processes. Related: SharedMind, MasterApprentice
SharedMind - Work closely with other developers to combine knowledge and catch each other's blind spots. Two minds working together often produce insights neither could reach alone. Related: TechnicalCommunity, BuildingBridge
FlowingFeedback - Structure code reviews and feedback to maintain development flow rather than creating bottlenecks. Feedback should accelerate learning, not slow down progress. Related: BuildingBridge, TightLoop
BuildingBridge - Respond to ideas with "Yes, and..." rather than "Yes, but..." to build on others' contributions. Constructive dialogue creates better solutions than defensive reactions. Related: SharedMind, FlowingFeedback
Learning & Expertise Patterns
MasterApprentice - Learn directly from experts through observation, imitation, and guided practice. The master-apprentice relationship transfers tacit knowledge that books cannot convey. Related: CraftPath, ArtisanMind
CraftPath - Follow a deliberate progression from novice to expert, focusing on fundamentals before advanced techniques. Mastery requires patient development of core skills. Related: MasterApprentice, ThinkingMirror
ThinkingMirror - Regularly reflect on your thinking processes and decision-making patterns. Self-awareness about how you think improves both learning and problem-solving. Related: ActiveReflection, InstinctiveChoice
ActiveReflection - Think consciously about your actions and decisions while performing them, not just afterward. Real-time reflection improves performance and builds expertise faster. Related: ThinkingMirror, PresentMoment
InstinctiveChoice - Develop pattern recognition that allows rapid decision-making based on experienced intuition. Expert programmers often know the right answer before they can explain why. Related: PatternHunting, ArtisanMind
Current Status
Phase 1: Foundation Patterns (In Progress)
Completed:
TinyExperiment ✓ - 패턴 언어 형식으로 완성, 검증됨
Next Priority:
DataAsFoundation - 로직 단순화의 핵심
TwoWorlds - 사고 체계의 기본
Remaining Foundation:
Validation Results
첫 번째 패턴 TinyExperiment의 스토리 구조가 검증되어 패턴 언어로서의 가능성을 확인했습니다.
Implementation Strategy
Phase 1: Core Foundation (Current)
가장 기본이 되는 5-6개 패턴을 완성하여 전체 구조의 기반을 마련
Phase 2: TDD & Design Patterns
TDD와 설계 관련 패턴들을 체계화 (10-12개 패턴)
Phase 3: Collaboration & Learning
협업과 학습 관련 패턴들을 완성 (8-10개 패턴)
Next Actions
Immediate (This Week)
DataAsFoundation 패턴 작성 시작
TwoWorlds 구조 설계
- Foundation 패턴들 간의 연결 관계 정의
Short Term (This Month)
- Foundation 레벨 5-6개 패턴 완성
- 패턴 언어로서의 일관성 검증
- Phase 2 패턴 우선순위 확정
Pattern Structure Template
각 패턴은 Alexander 방식을 따릅니다:
Context - 상황과 배경
Problem - 구체적인 문제와 갈등
Solution - 해결 방법과 원리
Examples - 실제 적용 사례
Related Patterns - 연결된 다른 패턴들
Progress Log
Recent Achievements
- 원본 문서에서 27+개 패턴 목록 정리 완료
TinyExperiment 패턴 완성 및 검증
- 3단계 구현 전략 수립
- Foundation 레벨 우선순위 확정
Lessons Learned
- 전체 패턴 목록을 먼저 정리하는 것이 중요
- 스토리 우선 접근법의 효과 확인
- 패턴 간 연결 관계의 복잡성 인식