juanatsap
d95c62bad4
Remove 557-line server-design.md from _go-learning/architecture - content is now covered in updated architecture documentation with real implementation examples and test coverage.
130 lines
4.9 KiB
Markdown
130 lines
4.9 KiB
Markdown
# 🎓 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.
|