Content deleted Content added
Mindmatrix (talk | contribs) m revert - please archive comments, don't delete them |
|||
(12 intermediate revisions by 11 users not shown) | |||
Line 1:
{{Talk header|search_term=refactoring}}
{{WikiProject banner
{{WikiProject Software | importance = }}
}}
==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.
Line 49 ⟶ 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 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 161 ⟶ 163:
== 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)
|