|
|
|
|
|
by victorNicollet
1547 days ago
|
|
I share their opinion. I understand "Do the simplest thing" to mean "ignore any additional insights you may have". If I know that a class will need to be accessed from multiple threads, I am not allowed to use locks, concurrent data structures or lock-free patterns until I add the first test that checks for multiple thread access. When that happens, I need to throw away almost all of the previous implementation. The same happens for any special data structure or algorithm that I know in advance will be necessary to solve the high-level problem, but it takes tens of tests to reach a point where the "simplest solution" no longer works. As an exercise, consider implementing a Union-Find data structure while constraining yourself to never writing a line of code that is not the simplest thing to solve the current test. My experience has been that it's better in those cases to construct a unit testing roadmap so that: - you incrementally build the correct solution
- you throw away as little code as possible
- throughout the process, you minimize the amount of code not covered by a test |
|
Who's imposing that constraint on you? Why? Can't you negotiate your way out of that?