One more thing... here’s a gem that is worth sharing, which I believe is attributable to Chris Raser.
The Cycle of Misery by Chris Raser
The code for the new feature is “too simple to test.”
The code grows.
Each change is “too simple to test.”
The changes start to interact.
And produce strange edge cases.
Some of these edge cases are intentional, some are accidental.
Other code is built that depends on the current, undocumented behavior.
The actual requirements are lost to time.
The code is now “not really testable.”
The code has become thousands of lines of if-else chains.
Tons of copy-and-pasted code.
Rife with side-effect booleans.
It has half a billion possible states.
And cannot be understood by mere mortals.
Nor refactored without risk to the business.
A new feature is needed.
A bright, shiny new bit of code is created.
Because adding anything more to the old code is madness.
The code for the new feature is “too simple to test.”
Exactly this. The "Gilded Rose" kata is a great illustration of this principle in action. I've had the pleasure, on no small number of occasions, of diving into those files with many thousands of lines, some functions in the many hundreds of lines, and trying to sort them out so that you can confidently add new functionality. As Sandi Metz illustrates on her excellent talk on the Gilded Rose, sometimes the best (only?) way out of those messes is to rewrite from scratch. If you don't have good, intentional, design-oriented tests to tell you what the intent of each part of the code is, you may well be looking at several months of effort to get back to full functionality. The only way to prevent it is writing good tests at every step. Whether TDD or ITL, get those tests in early while you know what it is you've written and why! >.<
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
One more thing... here’s a gem that is worth sharing, which I believe is attributable to Chris Raser.
The Cycle of Misery
by Chris Raser
The code for the new feature is “too simple to test.”
The code grows.
Each change is “too simple to test.”
The changes start to interact.
And produce strange edge cases.
Some of these edge cases are intentional, some are accidental.
Other code is built that depends on the current, undocumented behavior.
The actual requirements are lost to time.
The code is now “not really testable.”
The code has become thousands of lines of if-else chains.
Tons of copy-and-pasted code.
Rife with side-effect booleans.
It has half a billion possible states.
And cannot be understood by mere mortals.
Nor refactored without risk to the business.
A new feature is needed.
A bright, shiny new bit of code is created.
Because adding anything more to the old code is madness.
The code for the new feature is “too simple to test.”
Exactly this. The "Gilded Rose" kata is a great illustration of this principle in action. I've had the pleasure, on no small number of occasions, of diving into those files with many thousands of lines, some functions in the many hundreds of lines, and trying to sort them out so that you can confidently add new functionality. As Sandi Metz illustrates on her excellent talk on the Gilded Rose, sometimes the best (only?) way out of those messes is to rewrite from scratch. If you don't have good, intentional, design-oriented tests to tell you what the intent of each part of the code is, you may well be looking at several months of effort to get back to full functionality. The only way to prevent it is writing good tests at every step. Whether TDD or ITL, get those tests in early while you know what it is you've written and why! >.<