I was reading software engineering a practitioner's approach when I came across this question. I think the answer is no but I don't have much of a valid reason so I would like to hear other people's opinion .

closed as too broad by gnat, Robbie Dee, Euphoric, Doc Brown, Thomas Owens Apr 10 '17 at 11:34

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I'd suggest looking through the 'refactorings catalog' on Martin Fowler's refactoring website to get a sense of the typical size and scope of what a programmer might be doing to the code and/or design when they're 'refactoring' – Ben Cottrell Apr 9 '17 at 18:39
  • 1
    Did you look into Wikipedia? – Doc Brown Apr 9 '17 at 18:59
  • 1
    I really think that reading some basic information about refactoring should answer the question. Why exactly do you think it is unclear and why exactly would you answer "no" to that question. – Euphoric Apr 10 '17 at 4:21
  • While some argue that refactoring is a specific list of actions, the list is so large, that refactoring is actually a synonym for "creating software". – Frank Hileman Apr 11 '17 at 17:03

The answer is no because refactoring is explicitly not about "the entire design". Refactoring is about improving small aspects of the design, one at a time, without changing the functionality.

It is possible to do major overall changes in a design through a sequence of small refactoring steps, but it is not the typical case, nor can large changes always be done that way.

  • Is refactoring really inherently "small"? – user82096 Apr 10 '17 at 9:21
  • @dan1111 yes, according to Fowler's definition it is, at least the individual steps are. Of course it depends somewhat on what exactly you measure. Renaming a method that is used a lot may change a lot of code, but I'd say it's still a small change. – Michael Borgwardt Apr 10 '17 at 18:18

"Refactoring" is any change that tries to modify your source code without changing what the source code does. There is no requirement how small or big that change would be.

You would use refactoring to improve your source code. Often small changes will only lead to small improvements, while big changes may lead to big improvements. You decide what amount of changes produce the best ratio of improvement to effort.

There's always the risk that a change introduces a bug. Making small changes, you are less likely to introduce bugs, and if you do, they will be easier to find and fix. That's why refactoring is often done in a series of small steps. But refactoring may be done by throwing away some code and rewriting it from scratch, or doing small steps before a design is completely changed.

You just do what is best depending on the situation.

  • -1 If you're rewriting code, then you're rewriting it, not refactoring it. Refactoring means a very specific thing. Actually, a well defined list of things. Also, they don't "try" to modify the source without changing the behavior, they're guaranteed not to change the behavior. I hate to be pedantic about it, but it's that guarantee that is so very important. Otherwise a good answer. – RubberDuck Apr 10 '17 at 9:47
  • @RubberDuck I think you are splitting hairs with that objection. Of course refactoring is not supposed to change the behavior. But surely a developer might accidentally do so. It's appropriate to use the word "try" whenever humans are involved. And is refactoring really defined as "one of the 132 things that Martin Fowler mentioned in his book"? – user82096 Apr 10 '17 at 11:26
  • I'll give you that much @dan1111, when Humans are involved, mistakes will happen. However, if a refactoring is applied correctly, then there is a guarantee that behavior hasn't changed. That's such a vitally important detail this answer misses. As for the list, sure it can be extended, but any extension to it must also provide the same guarantee of retained behavior. – RubberDuck Apr 10 '17 at 11:30
  • @dan1111 it's using a lot of loose and squishy terminology to describe a very precise concept. There's already too much misconception about what refactoring is/isn't IMO. – RubberDuck Apr 10 '17 at 11:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.