I know that refactoring is \"changing the structure of a program so that the functionality is not changed\". I was talking with some of the guys I\'m working with on my fina
I think you are right, but arguing over the meaning of a word is not particularly interesting or productive.
http://en.wikipedia.org/wiki/Code_refactoring
Code refactoring is the process of changing a computer program's internal structure without modifying its external functional behavior or existing functionality, in order to improve internal non-functional properties of the software, for example to improve code readability, to simplify code structure, to change code to adhere to a given programming paradigm, to improve maintainability, to improve performance, or to improve extensibility.
I agree that refactoring code does include breaking existing code. Just make sure that you have unit tests so that you do not introduce any bugs, and the rest of the code compiles. Using refactoring tools like Resharper for C# makes this so easy!
I think that nobody can benefit of a too strong definition of the term 'refactoring'. The border between how you do perceive it and your colleagues is blurry and can be closer to their or your view depending on many facts. Since it's dynamic let's try to define it. First of all define the boundaries of the system or subsystem that you are trying to refactor.
If it is a method keep the name, input arguments, type of the returned value and possibly throwing statements fixed. Apply all the changes inside the method without changing how it is viewed outside.
If you refactor a class fix its public API and using rename variables, extract methods and all the other available techniques change the class to be more readable and/or more performant.
If the part of the code that you are refactoring is a package or a module do the refactoring inside of it possibly renaming classes, deleting, introducing interfaces, pushing/pulling code into super/subclasses.
With Martin Fowler's definition in mind,
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
... I think you are clearly right.
They also suggested things like changing data structures (like a Java LinkedList to an ArrayList), changing algorithms (using merge sort instead of bubble sort), and even rewriting large chunks of code as refactoring.
Changing an algorithm to something much faster is obviously not refactoring, because external behaviour is changed! (Then again, if the effect is never noticeable, perhaps you could call it refactoring after all - and also premature optimisation. :-)
This is a pet peeve of mine; it's annoying when people use the term sloppily - I've even come across some who might casually use refactoring for basically any kind of change or fix. Yeah, it's a hip and cool buzzword and all, but there's nothing wrong with plain old terms like change, rewrite or performance improvement. We should use those when appropriate, and reserve refactoring for cases when you are truly just improving the internal structure of your software. Within a development team, especially, having a common language for accurately discussing your work does matter.