3 ms·

I've been a TDD practitioner for a while now and I've lately started to question the value of doing the refactor step within the red/green cycle, even if the co

I've been a TDD practitioner for a while now and I've lately started to question the value of doing the refactor step within the red/green cycle, even if the code to make the tests green is a horrible kludge. Sure it's going to add technical debt to your project, but I can't shake the feeling like it is usually premature optimization of the maintainability of the code. Especially if it is a new feature, the requirements of maintainability seem like they're probably pretty low at first since you could find out that the feature was completely unnecessary in the first place for example. In a talk once, I heard an offhand remark that a good signal that a method needs refactored is if you're frequently fixing bugs in it because it signals you don't have a good grasp on what the method is supposed to be doing, and I've started trying to use that rule in side projects to optimize more for getting things done inthe few hours on nights and weekends I have to work on them.

amboar 13y ago
I've found a good approach to resolving the last issue is to write the documentation for the method. This forces you to think about what you want it to do outside of the implementation.
epochwolf 13y ago
The point of refactoring is to make the code cleaner and easier to understand.
- Stwerner 13y ago
  Right, but if you're never going to look at the method again and/or remove it next week for whatever reason, you've just wasted a bunch of time that could be spent on more valuable things. My thinking is definitely more focused on early stage start ups/personal side projects than bigger mature projects. But what I'm trying to get across is that I'm starting to wonder if "big clunky code base that's hard to support, maintain and understand" is in the same class of good to have problems for early stage start ups/side projects as "I chose a technology that is tough to scale to 500 million users" as long as you have a comprehensive test suite.
  - ollysb 13y ago
    I tend to vary the amount of refactoring I do depending on how much code is likely to depend on it. For instance I'd spend more effort in the DOM than I would in the controller (remember this is degrees of effort not lots/none). There's also nothing to stop you doing refactoring _before_ you start on a piece of code. Maybe you didn't think it would be worth refactoring at the time but now you're adding a new feature you can see that applying the refactoring would make it easier.

amboar 13y ago

I've found a good approach to resolving the last issue is to write the documentation for the method. This forces you to think about what you want it to do outside of the implementation.

epochwolf 13y ago

The point of refactoring is to make the code cleaner and easier to understand.

Stwerner 13y ago
Right, but if you're never going to look at the method again and/or remove it next week for whatever reason, you've just wasted a bunch of time that could be spent on more valuable things. My thinking is definitely more focused on early stage start ups/personal side projects than bigger mature projects. But what I'm trying to get across is that I'm starting to wonder if "big clunky code base that's hard to support, maintain and understand" is in the same class of good to have problems for early stage start ups/side projects as "I chose a technology that is tough to scale to 500 million users" as long as you have a comprehensive test suite.
- ollysb 13y ago
  I tend to vary the amount of refactoring I do depending on how much code is likely to depend on it. For instance I'd spend more effort in the DOM than I would in the controller (remember this is degrees of effort not lots/none). There's also nothing to stop you doing refactoring _before_ you start on a piece of code. Maybe you didn't think it would be worth refactoring at the time but now you're adding a new feature you can see that applying the refactoring would make it easier.