Content deleted Content added
Add WikiProject Computing Template using AWB |
Mindmatrix (talk | contribs) m revert - please archive comments, don't delete them |
||
| (41 intermediate revisions by 25 users not shown) | |||
Line 1:
{{Talk header|search_term=refactoring}}
{{WikiProject banner shell|class=Start|
{{WikiProject Software |
}}
==deleted paragraph about refactoring historically being avoided==
The paragraph about refactoring being historically avoided in general is wrong. It's long been recognized as the right thing to do but often only been put off for lack of resources and automated tools.
[[Special:Contributions/132.160.49.90|132.160.49.90]] ([[User talk:132.160.49.90|talk]]) 18:59, 19 September 2013 (UTC)
==(function calling from functions)==
(heading inserted for readability ... said: [[User:Rursus|Rursus]] ([[User talk:Rursus|bork²]]) 08:01, 9 July 2009 (UTC))
'''''Can'' anyone help me on the following sentence?'''
Line 27 ⟶ 32:
::In software engineering, the term 'factorization' was introduced by Peter Deutsch. I don't have the source paper right now, but I believe that he defined factorization to be the distribution of responsibilities among classes in object-oriented software system. So, refactorization should mean re-distribution of these responsibilities. [[User:Pdemb|Pdemb]] 19:46, 17 September 2006 (UTC)
:::I know this is an old discussion, but just in case anyone's still interested, the earliest use of the term "factorization" (or at least a related term) to refer to splitting responsibilities of code between different modules that I'm aware of was by [[Edsger Dijkstra]] in his 1972 Turing Award Lecture; he used the term "well-factored" on a number of occasions to describe software that adhered to good design principles. Quite clearly, he was not talking about object-oriented systems at the time. [[User:JulesH|JulesH]] ([[User talk:JulesH|talk]]) 16:01, 26 March 2009 (UTC)
:::Thank you guys! But CompSci doesn't use language as other sciences or tech spheres. One might have wished that at the very least the terminology would have be coordinated towards maths, engineering and itself, but consider CompSci "vector" vs. Math "vector", CompSci C++ "method" vs. general engineering and science "method" and CompSci "method" for that part, CompSci "factorization" vs. Math "factorization". Many sciences blather around like deaf fools, but CompSci gives me gooseflesh of horror. ... said: [[User:Rursus|Rursus]] ([[User talk:Rursus|bork²]]) 08:08, 9 July 2009 (UTC)
== Which type of testing ensures that refactoring does not change the behavior of the code ==
Unit tests, especially automated ones in the context of test-first or test-driven development, ensure that refactoring does not change the behavior of the code. [[User:Rodasmith|The Rod]] 18:53, 30 September 2005 (UTC)
I find that after refactoring is done, unit testing misses a bunch of ingegrated issues - so do a full run test after refactoring. <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/212.150.171.20|212.150.171.20]] ([[User talk:212.150.171.20|talk]]) 15:33, 30 November 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->
:Frequent full test runs are very useful and using a continuous integration server is a convenient way of doing that. But unit tests can be run after every single refactoring step. If you follow TDD, then it's not something you do only after an hour of refactoring. If you use JUnit Max then it automatically runs your unit tests all the time, in the same way that Eclipse continuously compiles your code and adds squiggly lines as appropriate. [[User:Mmeijeri|Martijn Meijering]] ([[User talk:Mmeijeri|talk]]) 16:41, 30 November 2010 (UTC)
== Tools ==
Line 35 ⟶ 47:
Would it be appropriate to add information about tools that support refactoring, in this page? (For example, Eclipse etc)
--[[User:Peterl|peterl]] 01:43, 4 August 2006 (UTC)
:[[Code_refactoring#Automated_code_refactoring]] now exists but is in need of citations. ~[[User:Kvng|Kvng]] ([[User talk:Kvng|talk]]) 15:23, 11 December 2018 (UTC)
== Factorization example ==
Line 43 ⟶ 57:
An article on Refactoring with no reference to [[Code Smell]]s? Ideally it should right up there in the introductory para. No later than the source code section.
[[User:DSParillo|DSParillo]] 16:58, 17 January 2007 (UTC)
:Currently discussed in the [[Code_refactoring#Motivation|first section]] of the article. ~[[User:Kvng|Kvng]] ([[User talk:Kvng|talk]]) 15:27, 11 December 2018 (UTC)
==Spin-off proposal==
Line 96 ⟶ 112:
I'm going to remove improving performance from the list of reasons to refactor. [[User:JulesH|JulesH]] ([[User talk:JulesH|talk]]) 13:00, 12 March 2009 (UTC)
:In fact, I'd go further and say that 'external non-functional' requirements are not part of refactoring, and that it is always (rather than usually) performed for one of the reasons in the list, which is in fact a superset of Fowler's definition. [[User:JulesH|JulesH]] ([[User talk:JulesH|talk]]) 13:33, 26 March 2009 (UTC)
== Redesign (software) ==
In regards to the article [[Redesign (software)]], I read that this is apparently "Code refactoring" applicable to the entire software solution. Do you think that the redesign article needs to exist, since the difference between the two appears to be scale - and that would be subjective (i.e. how much code can we refactor before its considered redesign)? My opinion is that article should simply redirect here... thoughts? [[User:Jwoodger|Jwoodger]] ([[User talk:Jwoodger|talk]]) 00:28, 9 February 2010 (UTC)
: Refactoring applies small behaviour preserving changes while redesign deeply changes the code and thus behaviour. I do not think this is comparable at all since the scale and impact are totally different. [[User:JnRouvignac|JnRouvignac]] ([[User talk:JnRouvignac|talk]]) 07:52, 24 November 2016 (UTC)
== Can't see the forest for the trees==
I want to emphasize, as someone who's done this for a living at times, that the '''refactoring process''' and '''a refactoring''' need to be distinguished. While a single "refactoring" ought not to make any changes in functionality, the purpose of doing a series of refactorings is to '''support''' changes in functionality. --[[User:Ed Poor|Uncle Ed]] ([[User talk:Ed Poor|talk]]) 21:51, 4 February 2011 (UTC)
== Most of this article is naive ==
I have read this article and it makes me so depressed to observe the naivity of the programmers who have written it and many others who have subsequently commented about it without knowledgeable criticism.
It is heavily OOP oriented and mired in [[Obfuscation|obfuscation ]] and completely unsupported claims. The history section is mostly bunkem - ludicrous comments such as "In the past refactoring was avoided in development processes" displays an ignorance born of the current age. The statement "Although refactoring code has been done informally for years" demonstrates that the writer is seemingly aware that throughout software history refactoring has been performed - but then goes on to cite various papers from the quite "recent" past (1990's onwards). Programming has been taking place since the advent of computers (at least 40 years before then) and so has "refactoring" (it's just that no-one called it that until recently - Doh!). During my 40 years, I have never heard of the term "code smell" used but have seen its consequences.
In the overview section the statement "...If at any point a test fails, you undo your last small change and try again in a different way" displays how poor the training of programmers is today. What you should '''actually''' do is find out WHY something fails, not just try a different way. Sadly, however, I have discovered that this is precisely how many of this current generation of programmers "get by".
I have been programming for more than 40 years and "refactored" my own (and other people's) code from the very beginning. In fact, I constantly refactor in my head "on-the-fly" - whilst creating the code in the first place. This is how code should be built IMHO.
During coding, if you have "seen" the code before (for example three or more consecutive lines that are almost identical to ones you have written before), it is already time to consider refactoring by putting the code in a sub-routine (procedure/function) or making it into a reusable macro. Not only will this often make it quicker to write the rest of the program, but it means that the re-organized section of code is more transportable to your next program that might need it. It also means that if the code is subsequently used in another program, it has been partially tested by earlier programs. COPY and PASTE do not acheive the same result since very often the code is subtly changed after copying and probably results in more errors rather than less (the same statements are spread everywhere but have multiple versions - a definite increase in entropy).
I could go on but suffice it to say this article is very misleading. There is really no substitute for good programming and part of that is understanding the code that is being written in its context (so that when something doesn't work, you find out why, not try something new). <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/86.142.127.235|86.142.127.235]] ([[User talk:86.142.127.235|talk]]) 08:14, 19 August 2011 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
I concur. It's typical of many articles that spew opinion as if fact; some of which shut out or flame people with differing opinions who would make corrections. Rather than relying on factual evidence, there's a tendency to accept content generally on consensus of those most dedicated to pushing their views. I've done my part here to incrementally address the problem, but there's a long way to go and it involves a systemic problem, and there's no guarantee that positive changes won't be reverted, and many like me who do real research & development don't have the time to deal with the problem appropriately.
[[Special:Contributions/132.160.49.90|132.160.49.90]] ([[User talk:132.160.49.90|talk]]) 19:11, 19 September 2013 (UTC)
== why is the refactoring browser "so-called" ? ==
Which tool is older than the Refactoring Browser for VW Smalltalk from http://www.refactory.com/tools/refactoring-browser ?
A tool in VA Smalltalk ? But that team wrote eclipse ... was there one in IBM workbench ? Was there one in the Borland C++ IDE for OS/2 ?
Which Object Pascal had such a tool ?
But it is "so-called" ... because an EDITOR is not a REFACTORING tool any more than the bogey under an aircraft is an airfoil. The bogies add drag, not lift. And eclipse ?
G. Robert Shiplett 21:51, 23 July 2013 (UTC)
== Reengineering is NOT refactoring ==
Right now Reengineering (software) points to this article. That is an error. Refactoring is not re-engineering. Re-engineering is analyzing code in legacy environments to capture designs, business rules, and/or to automate transformation of the code into a more maintainable form. Refactoring is just a normal part of the evolution of an object-oriented systems. They are related but different concepts. --[[User:MadScientistX11|MadScientistX11]] ([[User talk:MadScientistX11|talk]]) 21:44, 4 January 2014 (UTC)
:Sounds like the same thing to me, one is refactoring done during normal development, the other is long overdue refactoring that should have been done during development but wasn't. Refactoring simply means making tiny behaviour preserving transformations that make code easier to read and maintain. [[User:Mmeijeri|Martijn Meijering]] ([[User talk:Mmeijeri|talk]]) 22:09, 4 January 2014 (UTC)
::No they aren't the same thing at all. They involve similar types of activities and tools but they are fundamentally different. Analyzing some old assembler or COBOL code to understand the control flow or the business logic is re-engineering. Taking a Java system and reworking it to make it more re-usable, maintainable, etc. is refactoring. In refactoring you are using the same paradigm and language for the before and after. In re-engineering you are usually working in a different paradigm (code that wasn't designed with OO) and certainly in a different programming language. --[[User:MadScientistX11|MadScientistX11]] ([[User talk:MadScientistX11|talk]]) 04:21, 5 January 2014 (UTC)
:::OK, that's a substantial difference, but it seems to me refactoring could still be a large part of it. I once worked on a numerical code that had originally been written in Fortran, had been run through f2c after a couple of years and then been maintained for a couple of years. I thoroughly refactored it into more OO C++. Running something through f2c is still a behaviour preserving transformation, though the immediate end result isn't more readable, so it's a bit of a stretch to call it refactoring. [[User:Mmeijeri|Martijn Meijering]] ([[User talk:Mmeijeri|talk]]) 10:50, 5 January 2014 (UTC)
::::I agree they are related. Conceptually I would say Refactoring is a kind of re-engineering. We have to be careful to distinguish words from their English use and from specific meanings word have to IT people. So if we are talking just English word meaning than I agree Refactoring is a kind of re-engineering. But for at least some IT people, if you look for example in old reports on Gartner or Forrester before Y2K the phrase "software re-engineering" has a very specific meaning, it means recapturing design from legacy systems which in virtually all cases weren't designed with an Object-Oriented model. I don't think software re-engineering is in vogue now the way it was before Y2K. Anyway, it's not a big deal, I was just trying to link an article to "software re-engineering" where I was talking about recovering designs from COBOL and was surprised that the link ended up here. [[User:MadScientistX11|MadScientistX11]] ([[User talk:MadScientistX11|talk]]) 14:16, 5 January 2014 (UTC)
== merge with [[Rewrite (programming)]] ==
{{Discussion top|result=The result of this discussion was to NOT MERGE with [[Rewrite (programming)]]}}
I am against this merge. Too often people confuse refactoring and rewrite. They are not the same thing at all.
Refactoring applies small behaviour-preserving changes, while rewrite means throwing away the existing code and restarting from scratch. Refactoring should retain bugs like for like, while a rewrite removes all the previously known bugs while it adds new unknown ones (hopefully less than before and/or less severe). The process of refactoring can be stopped at any moment and the system remains functional at all times. On its hand the rewrite must be completed before it can replace the previous code. If it is not completed then the new code is [[dead code]] or [[unreachable code]] and is immediately subject to [[software rot]]. [[User:JnRouvignac|JnRouvignac]] ([[User talk:JnRouvignac|talk]]) 08:03, 24 November 2016 (UTC)
:I agree. Although, I think your definition of refactoring is just a bit too rigorous. In the real world, at least in my experience, people can sometimes make minor changes to the functionality while doing refactoring. So for example, if I find that I have some class, hexagon that is created all by itself and then I realize it should inherit from the shape class, I would consider that refactoring even though the behavior may change (e.g., by making hexagon a subclass of shape it may inherit new behaviors that weren't originally needed but now are). But thats just a quibble, in general I definitely agree rewriting or re-enginnering code is not the same as refactoring (I said similar things in an earlier thread). --[[User:MadScientistX11|MadScientistX11]] ([[User talk:MadScientistX11|talk]]) 16:27, 24 November 2016 (UTC)
I am against merging this document. The concept and term of refactoring come up in computer science education and literature quite often. Some schools even have entire courses dedicated to refactoring and improving code. I myself found this Wikipedia page when searching for a concise, elegant definition of refactoring. This is a very different concept than simply rewriting a program. When rewriting code, it is expected that the behavior will change. When refactoring code, it is expected that it will not. <!-- Template:Unsigned IP --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/174.16.14.244|174.16.14.244]] ([[User talk:174.16.14.244#top|talk]]) 02:59, 12 March 2017 (UTC)</small> <!--Autosigned by SineBot-->
I oppose this merging too, and I agree with the previous comments by MadScientistX11 and "unsigned". Refactoring and rewriting are completely different things. To abuse a car analogy, it's the difference between fixing your car and buying a new one. [[User:Dserodio|Dserodio]] ([[User talk:Dserodio|talk]]) 22:25, 30 May 2017 (UTC)
{{Discussion bottom}}
== Motivation section: debt vs payment ==
The metaphor of technical debt is introduced, and then refactoring is cited as a payment of technical debt.
Is such a metaphor really helping the article? Doesn't this just say that fixing poorly-organized or poorly-planned code is better than not fixing it? (It doesn't take a genius to figure that out.) :)
I'm not sure why that part is kept. [[User:TooManyFingers|TooManyFingers]] ([[User talk:TooManyFingers|talk]]) 21:08, 8 July 2020 (UTC)
:Fixing poorly-organized or poorly-planned code comes with a cost and with the risk of introducing new errors. In a given business environment leaving such code as it is may be entirely reasonable at a given time. – [[User:Tea2min|Tea2min]] ([[User talk:Tea2min|talk]]) 07:52, 9 July 2020 (UTC)
== Messy change in History section ==
In the History section, I just removed the redundant "Griswold's Ph.D. thesis, ..." sentence. It was a very messy edit, since the contents of the refs were embedded in it, and had to be shuffled to the next sentence. The diff (changes) is a mess, but the end results are just the removal of the pesky sentence. [[User:BMJ-pdx|BMJ-pdx]] ([[User talk:BMJ-pdx|talk]]) 08:39, 12 May 2024 (UTC)
| |||