- Yair Mark
Based on the katas I did on the last day of the course high gear is where we have a better understanding of the problem. We write more focused tests that directly target the different equivalence partitions we need to work with.
Solving for What
When coding we generally think about how we are going to solve something instead of what we are trying to solve.
When TDD is done correctly Ive found you focus on what you need to solve by writing the tests first, then you work out how you get the test to pass by actually writing the production code for the system under test (SUT). When TDD is not done properly or at all it is out natural tendency as developers to think about how we are going to solve a problem when instead we should be focusing on what exactly we need to solve for. Solving for what has an interesting effect: you will likely end up with the minimal amount of code needed to solve the problem.
When doing POCs we should keep track of what technical debt we are introducing to achieve the POC. When we get past a certain number of technical debt items we should stop what we are doing and clean them up. The problem with POCs is they often have a tendency of turning into an MVP/pilot and getting put into production.
Various other rules
A few other interesting rules popped up during the course
The rule of 3
If you copy paste something a third time (ie there are 2 other versions of it) then you likely should move it to a common class. This should not be followed dogmatically but done so pragmatically rather - will it be easier to maintain if left duplicated? Eg if this is across projects and not in the same project where these projects can and do change at different rates?
This is a low gear technique where we try 3 different variants of test data to get a better understanding of code. For example with FizzBuzz triangulation for the Fizz case would involve writing a test for 3, 6 and 9 then once we are happy that these tests are passing correctly we combine them into one test that tackles Fizz.