Talk:Code refactoring

(function calling from functions)

(heading inserted for readability ... said: Rursus (bork²) 08:01, 9 July 2009 (UTC))

Can anyone help me on the following sentence? "After a certain point, it becomes clear that functions can benefit from using functions themselves."

I am translating this article to Chinese, but I can't catch it. Thanks.--202.99.60.155 02:11, 17 Jan 2005 (UTC)

It means that it is often useful to break a complex function into calls of less-complex functions. For example, a complex function that reads weather sensors, computes the wheather for next week and produces maps could be broken into three smaller functions that are called in sequence.

--Stephan Leclercq 09:04, 17 Jan 2005 (UTC)

In software engineering, refactoring is *strictly* bound to object oriented code. The term comes from 'factorization'. In OO design, 'to factorize' means 'to distribute responsibilities among classes and objects'.

If you want to talk about behaviour-preserving transformations in structural programs, (or in assembly code or declarative code or whatever) there are other terms, such as 'to restructurize' or 'to reengineer' or similar. Leave refactoring to OOP.

-- [Peter]

I disagree. Refactoring is not strictly bound to OOP. Refactoring is about behavior-preserving transformations, cleaning code, etc. Concepts that are common to all languages. It is true that some types of refactorings are more or less tied to OO concepts, but refactoring as a whole is not. --Henrik S. Hansen 16:16, 22 October 2005 (UTC)

AFAIK the word 'to refactor' comes from 'to factorize', which means 'to distribute responsibilities between objects and classes'. --Pdemb 11:55, 8 January 2006 (UTC)

"To factorize" means to express something as a product of factors. You can factorize a number, a polynomial, a matrix. It does not imply a distribution of responsibilities among objects, although often that's what it achieves. For example, if you factorize a positive-definite matrix into the product of two triangular matrices, the responsibility of solving the associated system of linear equations is distributed to the two triangular matrices as forward substitution and backward substitution, respectively. --SergioPi 15.03, 29 July 2006.

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. 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. 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: 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. 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. —Preceding unsigned comment added by 212.150.171.20 (talk) 15:33, 30 November 2010 (UTC)

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. Martijn Meijering (talk) 16:41, 30 November 2010 (UTC)

Tools

Would it be appropriate to add information about tools that support refactoring, in this page? (For example, Eclipse etc) --peterl 01:43, 4 August 2006 (UTC)

Factorization example

The factorization example given in the text has no relevance whatsoever to the fine art of refactoring. Please refactor this paragraph. Stud. polyt. Kalle Hagen 09:44 4 December 2006

Code Smells

An article on Refactoring with no reference to Code Smells? Ideally it should right up there in the introductory para. No later than the source code section. DSParillo 16:58, 17 January 2007 (UTC)

Spin-off proposal

I'd like this page to be only about code refactoring and the wiki-based idea of "refactoring" articles or talk pages be discussed in another page.

The intro is overly-general and imprecise:

Refactoring is the process of modifying a computer program or other material to improve its structure or readability, while explicitly preserving its meaning or behavior.

First off, it will change its behavior in many cases. It just won't change the results of the system tests. Only simply refactorings leave "behavior" essentially unchanged, such as the ExtractMethod facility found in Visual Studio.

The bit about preserving other text's "meaning" is misleading. When refactoring talk pages, we deliberately remove nasty-meaning language like "You're such a jerk about your edits" => "I disagree with your edits." --Uncle Ed 13:05, 9 February 2007 (UTC)

Paragraph 4 critique

The following is the start of the article's fourth paragraph:

There are however certain problems to overcome in refactoring. It is a comparably new idea and there is not enough experience over its long term effects, thus the limitations which apply to it are not yet studied enough. Another problem area of refactoring are the databases – in today’s 3 – tiered architectures the business layer is strictly related to the database schema, which makes the refactoring impossible or very difficult.

This paragraph is fairly weak, in both rhetoric and content.

"It is a comparably new idea and there is not enough experience over its long term effects" is oddly phrased, and I think the word "comparatively" is intended; "comparably" means similar or equivalent. The gist is inaccurate in my opinion. While the identifiable buzzword "refactoring" may only go back as far as the Fowler book, certainly the practice as informal "code clean-up" with minimal system behavior change has been going on for decades; it's a natural activity for anyone to undertake who's written a large code base and seen its entropy increase to the point that it's difficult to make changes.

The next sentence begins another rudimentary grammatical error - "area", is singular, "databases" is plural. The claim is also extremely over-simplified in its approach to architectural layers and styles. In today's N-tiered applications there is nearly always some layer of abstraction, however crude, between relational database tables and business objects, and a coherent approach to refactoring in either the business tier or the database tier would naturally look to that abstraction layer (be it ORM, JDBC/ODBC, or just a hard-coded translation module) to determine what's possible. One might even refactor to strengthen this translation layer first, and then refactor the target tier after looser coupling between layers has been achieved.

The rest of the paragraph exhibits similar problems. Hyphens are used to run sentences together; this is substandard form, appropriate for e-mail but not for a reference article. The interface difficulty described is commonplace, and the example solution offered just one of many approaches that could be taken. Overall I think the fourth paragraph should go, it's misleading and poorly written.

--Chriscorbell 21:07, 10 September 2007 (UTC)

References

I changed the inline links to references, and renamed the previous "references" section to "further reading". This is because I don't know what information specifically came from which sources. Could others add in-text citations for the information derived from from the books in "further reading"? -Frank.tobia 14:11, 26 October 2007 (UTC)

Software Methodology

I've made a small fortune by combining automated unit testing with code refactoring. From the very start, I doubled my programming speed and reduced my "bug rate" to near zero.

But while carefully avoiding "advocacy", I'd like to explain how refactoring works together with automated tests. Or perhaps it is better explained in Extreme programming? --Uncle Ed (talk) 02:03, 23 January 2008 (UTC)

I think your expertise would be greatly appreciated for this article. You can have a positive view of the subject of the article, as well as you adhere to Wikipedia's policy of keeping a neutral point of view throughout. I don't believe WP:COI applies here. I personally wouldn't mind a sub-section somewhere in this article about combining refactoring with testing, but perhaps extreme programming is a better article to go for. It's really up to you. -FrankTobia (talk) 03:48, 23 January 2008 (UTC)

Thanks. I rarely write software any way but Test first these days, unless I'm learning something completely new and I'm just experimenting with various methods and features. But once I'm comfortable with a new language or API (like PHP and all its file and string functions), I find it better to "write a failing test first" - and then "write just enough code to make the test pass". I guess this is Kent Beck's style.

I'll need someone to keep me honest, lest I lapse into effusive praise of test-first development. But I'm always open to being told to "step off" when I confuse advocacy and objectivity. --Uncle Ed (talk) —Preceding comment was added at 18:09, 23 January 2008 (UTC)

Haha, fair enough. I'm happy to keep you honest. Of course anything with a source would be amazing: I don't have access to those most excellent refactoring books myself. Let me know on my talk page if there are any related pages I should add to my watch list. -FrankTobia (talk) 01:35, 25 January 2008 (UTC)

Refactoring to improve performance?

Including this seems a little controversial to me. Performance is not a "non-functional" aspect of a system's behaviour. And while some refactorings clearly improve performance, and some techniques to improve performance are clearly refactorings, I think performance optimization is a distinct process. And as Fowler says in Refactoring:

Only changes made to make the software easier to understand are refactorings. A good contrast is performance optimization. Like refactoring, performance optimization does not usually change the behavior of a component (other than its speed); it only alters the internal structure. However the purpose is different.

I'm going to remove improving performance from the list of reasons to refactor. 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. 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? Jwoodger (talk) 00:28, 9 February 2010 (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. --Uncle Ed (talk) 21:51, 4 February 2011 (UTC)