Content deleted Content added
Line 116:
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 factoring 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).
| |||