cv-site/doc/_go-learning

🎓 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.