Nice article! I would have used another math example, though:
Realize that (7.x + 7.y) is in fact 7.(x+y)
I prefer this example better because:
there's no automated rule to do it (contrary to your fraction example)
the result of the factorization seems easier to read
and I think it better reflects what refactoring is.
I want to explore the design first, then I write my tests afterward.
There's a video from destroyallsoftware that explains how you can explore first, then throw all the code away, and rewrite it following TDD. It's interesting to watch.
how you can explore first, then throw all the code away, and rewrite it following TDD
For sure, sometimes its hard to make a start with something small and you need to explore the problem space a bit. So long as you have the discipline to throw that code away its all good.
I like your maths example but I was just trying to keep it as simple as possible to show the relationship between factorisation and refactoring :thumbsup:
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.
Nice article! I would have used another math example, though:
Realize that
(7.x + 7.y)is in fact7.(x+y)I prefer this example better because:
and I think it better reflects what refactoring is.
There's a video from destroyallsoftware that explains how you can explore first, then throw all the code away, and rewrite it following TDD. It's interesting to watch.
Cheers!
For sure, sometimes its hard to make a start with something small and you need to explore the problem space a bit. So long as you have the discipline to throw that code away its all good.
I like your maths example but I was just trying to keep it as simple as possible to show the relationship between factorisation and refactoring :thumbsup: