Refactoring is one of those terms in IT that gets bandied about as a good thing. Refactoring is meant to be the small incremental cleaning up of code to restructure it while leaving it functionally the same(1). Some folks say that re-writing is different as it changes this functional contract. What happens in the field however is different...
Refactoring tends to be done in small chunks and done incrementally around a specific area, for instance a single function or class. The refactoring tries to 'evolve' the code to make it better and does have some good theory behind it, but regrettably in the field I tend to see refactoring creating an incrementally more complex mess as parts are 'optimised' while the whole collapses. Refactoring in the field is also mostly done when you've got new functionality, so the idea of functional equivalence goes out the window its now just about refactoring as you develop a new requirement which means that the new requirement skews the refactoring.
This reality of refactoring in the field means that I often come across code that has gone through several refactors and each was tinged by the mentality of the developer undertaking a specific new piece of functionality, the refactors therefore are not making the code better but instead making it better to develop that one specific requirement.
For this reason I'm actually a big fan of re-writing and, whisper it quietly, I tend to find its quicker and produces better code, especially from a maintenance perspective. Now I could argue what I do is refactoring as I'm always rather anal around getting interface designs right and they tend to be rather stable as I put quite a bit of time into them. The reality though is that the body is completely changed behind the facade.
Re-writing works because I now know what I didn't when I first planned the internals. I know the additional requirements that I've received and the new information classes that I now must operate on. Recently I had a piece of code where I had spent a couple of 'refactors' making it 'better' and the code was a bit cleaner and more manageable. I then came across a bug which was proving rather hard to track (Objective C how I loathe you) and some new functionality I wanted to develop was adding complexity into the code... so it was re-write time.
About 60 minutes later there were 120 lines of code (SLOC) where previously there had been 300+, this clean down had removed the bug (which was to do, as ever, with memory allocation) and added in the new functionality. The new code had been quick to write as I now understood much better what the end-goal was thanks to new requirements through a few iterations and I'd a much better grasp on how all of the different classes needed to engage.
Functionally my class interface hadn't changed and the calling classes didn't need to change but its hard to claim what I did was a simple refactor as I trashed every single line of code and re-wrote from scratch based on the requirements & design.
Refactoring has become a short cut for 'don't do it well first time' and the reality of the field does not match the theory in the books. Too often the phrase is used to hide bad code, badly re-structured (and I'll admit that my first pass was in retrospect just that as I didn't know quite how Objective C and iOS worked).
Its time to come clean:
Sometimes its better and quicker to re-write than keep up the facade of 'refactoring'.
Refactoring tends to be done in small chunks and done incrementally around a specific area, for instance a single function or class. The refactoring tries to 'evolve' the code to make it better and does have some good theory behind it, but regrettably in the field I tend to see refactoring creating an incrementally more complex mess as parts are 'optimised' while the whole collapses. Refactoring in the field is also mostly done when you've got new functionality, so the idea of functional equivalence goes out the window its now just about refactoring as you develop a new requirement which means that the new requirement skews the refactoring.
This reality of refactoring in the field means that I often come across code that has gone through several refactors and each was tinged by the mentality of the developer undertaking a specific new piece of functionality, the refactors therefore are not making the code better but instead making it better to develop that one specific requirement.
For this reason I'm actually a big fan of re-writing and, whisper it quietly, I tend to find its quicker and produces better code, especially from a maintenance perspective. Now I could argue what I do is refactoring as I'm always rather anal around getting interface designs right and they tend to be rather stable as I put quite a bit of time into them. The reality though is that the body is completely changed behind the facade.
Re-writing works because I now know what I didn't when I first planned the internals. I know the additional requirements that I've received and the new information classes that I now must operate on. Recently I had a piece of code where I had spent a couple of 'refactors' making it 'better' and the code was a bit cleaner and more manageable. I then came across a bug which was proving rather hard to track (Objective C how I loathe you) and some new functionality I wanted to develop was adding complexity into the code... so it was re-write time.
About 60 minutes later there were 120 lines of code (SLOC) where previously there had been 300+, this clean down had removed the bug (which was to do, as ever, with memory allocation) and added in the new functionality. The new code had been quick to write as I now understood much better what the end-goal was thanks to new requirements through a few iterations and I'd a much better grasp on how all of the different classes needed to engage.
Functionally my class interface hadn't changed and the calling classes didn't need to change but its hard to claim what I did was a simple refactor as I trashed every single line of code and re-wrote from scratch based on the requirements & design.
Refactoring has become a short cut for 'don't do it well first time' and the reality of the field does not match the theory in the books. Too often the phrase is used to hide bad code, badly re-structured (and I'll admit that my first pass was in retrospect just that as I didn't know quite how Objective C and iOS worked).
Its time to come clean:
Sometimes its better and quicker to re-write than keep up the facade of 'refactoring'.
1 comment:
this is very nice tutorial i found a similar one here
http://thecafetechno.com/design-patterns/what-is-code-refactoring/
Post a Comment