# 🎓 Personal Go Backend Learning Knowledge Base

> **PRIVATE DOCUMENTATION** - This directory is gitignored and contains personal learning notes about Go backend development using this CV project as a practical learning ground.

## 📚 Purpose

This knowledge base exists to document **WHY** we make specific architectural and implementation decisions in Go backend development. While building this CV application, I'm using it as an opportunity to deeply understand:

- Go backend architecture patterns
- Package organization and dependency management
- Concurrency patterns (goroutines, channels)
- HTTP server best practices
- Code organization and maintainability
- Refactoring strategies
- Testing approaches

## 🗂️ Structure

```
_go-learning/
├── README.md                    # This file
├── architecture/                # System architecture explanations
│   ├── server-design.md        # Why goroutines, server lifecycle
│   ├── package-structure.md    # Package organization philosophy
│   └── dependency-graph.md     # How components interact
├── refactorings/               # Detailed refactoring documentation
│   ├── 001-cv-model-separation.md  # CV/UI model separation
│   └── ...                     # Future refactorings
├── patterns/                   # Go patterns and idioms
│   ├── error-handling.md       # Error wrapping, custom errors
│   ├── interfaces.md           # When and how to use interfaces
│   └── constructors.md         # Builder patterns, factory functions
├── best-practices/             # Go best practices with examples
│   ├── naming-conventions.md   # Package, func, var naming
│   ├── testing.md              # Table-driven tests, mocks
│   └── performance.md          # Profiling, optimization
└── diagrams/                   # Visual architecture diagrams
    ├── current-state/          # Before refactorings
    └── target-state/           # After refactorings
```

## 🎯 Learning Goals

### Short-term (During CV Project)
- [ ] Understand Go package organization best practices
- [ ] Master goroutine usage and server lifecycle
- [ ] Learn proper error handling patterns
- [ ] Understand interface design principles
- [ ] Practice test-driven development

### Medium-term (Job Interview Preparation)
- [ ] Explain architectural decisions confidently
- [ ] Discuss trade-offs between different approaches
- [ ] Demonstrate deep understanding of Go idioms
- [ ] Show practical experience with production patterns

### Long-term (Professional Growth)
- [ ] Build intuition for clean architecture
- [ ] Develop systematic refactoring skills
- [ ] Master concurrent programming patterns
- [ ] Create reusable knowledge base for future projects

## 📖 How to Use This

### When Learning:
1. Read the relevant document before making changes
2. Understand the **WHY** behind the pattern
3. Implement the change
4. Document any new insights or questions

### When Interviewing:
1. Review architecture documents
2. Practice explaining decisions
3. Prepare to discuss trade-offs
4. Reference specific examples from this project

### When Stuck:
1. Check if there's a relevant pattern documented
2. Look at similar refactorings
3. Review best practices
4. Add new learnings to prevent future confusion

## 🔄 Living Document Philosophy

This knowledge base is **constantly evolving**. Every time we:
- Make an architectural decision → Document WHY
- Refactor code → Capture lessons learned
- Discover a better pattern → Update best practices
- Face a challenge → Record solution and reasoning

## 🚀 Current Focus: CV Model Refactoring

**Active Learning**: Separating CV domain models from UI presentation models

**Key Questions Being Answered**:
- Why separate concerns in Go packages?
- How does package structure affect testability?
- What are the trade-offs of package organization?
- When to use interfaces vs. concrete types?
- How to manage dependencies between packages?

See: `refactorings/001-cv-model-separation.md` for detailed analysis.

## 💡 Philosophy

> "The best way to learn is to teach. The best way to understand is to document WHY, not just WHAT."

This knowledge base forces me to:
1. **Question everything**: Why this approach over alternatives?
2. **Document reasoning**: Capture decision-making process
3. **Learn from mistakes**: Update when discovering better patterns
4. **Build intuition**: Develop mental models of good design

## 📊 Progress Tracking

- **Start Date**: 2025-11-20
- **Documents Created**: 0
- **Refactorings Documented**: 0
- **Patterns Catalogued**: 0

---

**Remember**: This is a safe space for learning. It's okay to:
- Document wrong assumptions (then correct them)
- Ask "stupid" questions
- Explore multiple approaches
- Change your mind with new information

The goal is **deep understanding**, not perfection.