Emmanuel Valverde Ramos
Índice
- Context
- The methodology we are going to follow
- The roadmap
- Suggestions before start
- Level 1 - Emerging design
- Level 2 - Working with collaborators and Test doubles
- Level 3 - Double loop - Outside-in - BDD
- Level 4 - Design patterns
- Level 5 - Working with legacy code
- Level 6 - Architectural patterns
- You can find me at
Context
In the world of software development, where things often become outdated in less than 3 months, there exists a set of practices and principles that have remained unchanged for over 20 years. These practices and principles form the foundation of software development. As a professional, one of my core values is to provide the highest value to the end user, with the best possible quality, and at a sustainable pace. This is why one of the practices I frequently employ is Test-Driven Development (TDD), which instills confidence in the software I produce.
It's common for professionals to undergo training or assist their colleagues in enhancing their skills, with Test-Driven Development being one of the practices I often teach and practice. Through my participation in software crafter communities, I've had the opportunity to witness firsthand the learning journeys of others. This experience provides me with an interesting perspective when it comes to teaching such practices.
One of the most frequently asked questions is "How to learn Test-Driven Development?" This is quite understandable, given the absence of a concrete guide on learning Test-Driven Development. Consequently, I reflected on my own learning experience, how I have taught my colleagues or others starting their journey, and what has been crucial for them. Drawing from this knowledge, I decided to create this roadmap to assist people in answering this seemingly recurrent question.
The methodology we are going to follow
In this roadmap, we are going to apply something similar to Bloom's Taxonomy, so having some concept of what it is could somehow be beneficial.
The way we will apply Bloom's Taxonomy is as follows:
- Identify what the learning outcome of the kata could be, that is, what concepts one could learn through this kata and which ones they would like to learn.
- Seek the concepts to learn and comprehend them, things that could help in case we want to reinforce our learning:
- Joining a book club or creating one.
- Engaging in communities of software crafters where these types of concepts are discussed.
- Create a summary of the concepts you have read/seen to try to understand what you have learned and compare this with your book club or community peers.
- Practice the concepts with small exercises like katas, where the emphasis is not on completing these exercises, but on practicing and learning the concepts.
- Re-work the exercise or resume based on the feedback and try to learn from it.
- Improve your summary based on your experience
- Create a different kata where you work on one of the concepts learned.
- Publish your kata so that others can learn from it.
The roadmap
When I created this roadmap, I designed it so that following it would be identical to how we learned to program, that is, working from simpler to more complex concepts and starting with the same concepts that people typically encounter when learning programming:
- Introduction:
- Variables
- Conditionals
- Loops
- Algorithms
- Data structures
- Object Oriented Programming
- Patterns
- Architecture
Suggestions before start
Level 1 - Emerging design
This is why it starts with a progression from conditionals and algorithms to object-oriented programming.
Katas for this level:
- FizzBuzz: This kata focuses on conditionals, and parameterization of different cases, and emphasizes taking baby steps to reinforce the importance of "fake it until you make it" and ensuring that tests fail only for the right reasons. One of the recommendations we often make is for participants to follow this sequence during the kata:
- Iteration 1: TDD cycle + Baby steps
- Iteration 2: Work on the TPP
- Iteration 3: If a test fails, revert changes (Test commit or revert)
- Anagram: This kata focuses on conditionals, and parameterization of different cases, and emphasizes taking baby steps to reinforce the importance of "fake it until you make it"
- Iteration 1: TDD cycle + Baby steps
- Iteration 2: Work on the TPP
- Leap year: This kata introduces a slightly more complex algorithm, perfect for working with nested conditionals.
- Iteration 1: TDD cycle + Baby steps
- Rock Paper Scissors Kata: This kata involves working with conditionals, parameterization, business specifications similar to these, and an introduction to the first key-value data structure.
- Iteration 1: TDD cycle + Baby steps
- Iteration 2: Parameterization
- Iteration 3: No else statement
- Roman Numeral: Reinforcement of the concept of loops and basic key-value structures. A highly illustrative kata of what the Transformation Priority Premise TPP is.
- Iteration 1: TDD cycle + Baby steps + Parameterization
- Iteration 2: Work on the TPP
- Iteration 3: If a test fails, revert changes (Test commit or revert)
- Mastermind: A kata with a simple algorithm where
- Iteration 1: Fake it until you make it, TDD Cycle, baby steps
- Iteration 2: Fake it until you make it, TDD Cycle, baby steps, test parameterization, clean code
- Iteration 3: The above + OOP
- String Calculator: The goal of this kata is the use of iterative incremental work, with conditionals and parameterized tests.
- Iteration 1: TDD cycle + Baby steps
- Iteration 2: Work on the TPP
- Iteration 3: If a test fails, revert changes (Test commit or revert)
- Build a Christmas tree: This kata involves basic algorithmic work while teaching how to write output tests and encapsulate concepts.
- Iteration 1: TDD cycle + Baby steps + Learn to write tests for output with a specific format
- Iteration 2: Learn about Fixtures
Could you make the code chosen by the codemaker generated by the game?
How would your design change?
What tests would you need?
Level 2 - Working with collaborators and Test doubles
Level 3 - Double loop - Outside-in - BDD
Level 4 - Design patterns
Level 5 - Working with legacy code
Level 6 - Architectural patterns
