Arjen writes "Artima has had a conversation with Martin Fowler, one of the gurus on software development today. It consists of six parts. Parts one, two, three, and four are available now; the rest will appear the next weeks."
Developers love him; Managers hate him
by
dagg
·
· Score: 5, Interesting
Martin Fowler's books that outline such things
as extreme programming and refactoring are tops
in my opinion. But in my experience, many
middle-tier and upper-level managers think that
such concepts are useless and timewasting.
Re:Developers love him; Managers hate him
by
Spruce+Moose
·
· Score: 5, Informative
Refactoring is often about injecting the last good idea you had into working code.
Refactoring isn't about making your project buzzword compliant or supporting distributed OLE-foo++. That's adding new features.
From the article:
Martin Fowler: Refactoring is making changes to a body of code in order to improve its internal structure, without changing its external behavior.
Refactoring is usually saying "hey, I implemented that function the wrong way so I'm going to rewrite it properly". The right way of doing something is often obvious after coding it up the wrong way.
Re:Developers love him; Managers hate him
by
vbweenie
·
· Score: 5, Insightful
Refactoring is also not just something you do (or not) after you've finished (i.e. shipped / deployed). It's something you do as you go along, during the process of building the thing. If you need to refactor substantially after you've finished, then it may be that you didn't refactor enough as you went along.
Refactoring is a fancy word for what many good programmers who are not geniuses do already, a few good programmers who are geniuses don't need to do, and a lot of bad programmers who may or may not be geniuses don't do enough. Speaking as an OK programmer who is not a genius, I feel I need all the help I can get, be it from test-infection or from taking a considered approach to cleaning up after myself.
Periodic refactoring helps me keep abreast of shifting requirements; it isn't about prettying-up something that's about to become obsolete anyhow, but about keeping a check on creeping duplication and tacit dependencies so that the code can absorb new requirements instead of being broken by them.
-- Experience is a hard school, but fools will learn no other.
Re:Developers love him; Managers hate him
by
Leeji
·
· Score: 5, Interesting
Refactoring is often about injecting the last good idea you had into working code.
I've got to disagree with you on this one. Refactoring isn't about injecting good ideas into working code, it's about making sure that those new requirements you got last week didn't create spaghetti code. In a development world were you design from a static set of requirements, Refactoring really doesn't have much of a place. In that world, you have a valid point: if a developer can't do it right the firt time, round two won't be much better.
However, that's not the world I live in, and it's not the world that anybody I know lives in. Then again, I don't have friends at NASA. We live in a more realistic development world that changes reqirements after we've designed our framework. We live in a development world where the evolving system makes the customer reconsider their original decisions. Since you didn't design the system with these new requirements in mind, you're usually patching functionality on top of what you got.
Refactoring is about reviewing this patch-work to make sure that the code is written as though it were designed that way from the beginning.
Certain agile methodologies (especially XP) treat refactoring as a tenet. Customers never give you a complete spec, and you never want one. They give you "stories" that you implement quickly and minimally. You don't over-engineer to support infinite extensibility via Web Services and a plugin architecture (etc,) unless the story asks for it.
When your latest minimal implementation starts looking ugly or hacky (ie: 4 page switch statement) then you refactor until the code properly "expresses its intention."
You had some good points, but I think you are a little mistaken about when refactoring comes into play.
--
It all goes downhill from first post...
Missing some crucial bits there...
by
ssclift
·
· Score: 5, Insightful
What bothers me, is that the process being plugged here doesn't address methods for keeping all of the expressions of the program consistent. Tests are a (limited) alternate expression of the program's functionality that are trivial to compare to the original. Yes, they need to be good. What about documentation (which I define separately from annotated indexing, such as doxygen or Javadoc produce), which is another, separate expression (usually not in an executable language) of the program?
Until these authors address how to keep the entire structure from docs down to code consistent during a refactoring I think they are missing an important point. I've pointed this way before on Slashdot, but the only good way I've found for ensuring that non-executable forms of the program are consistent with executable forms, is formal Software Inspection (see Gilb's stuff at Result Planning ). I've found that the more versions of the code there are (requirements, user docs, code itself, tests etc.) that are kept truly consistent, the more likely it is you will not make mistakes in the final expression (the code you ship).
The refactoring process can be even less "like walking a tightrope without a net"; you're net is a web built out of the relationship between all of these documents, not just the code and tests!
Funny to see old terminology being the 'new' thing
by
Junks+Jerzey
·
· Score: 5, Interesting
Pick up any Forth book from the early 1980s and a major theme is that of properly factoring your code. I was always surprised that no one ever picked up on the term--until the last several years, that is.
Re:Refactoring may very well be a waste of time
by
Ed+Avis
·
· Score: 5, Insightful
I think the point of refactoring is that it happens exactly when you add a new requirement. You have some code that does X. Now you have a requirement that it do Y as well. There is a clean way to add feature Y, but it would need restructuring the existing code first. So as a first step you refactor the code so it still does X - 'but better!' - and then you can add code to do Y more easily. Doing the two steps separately - the XP rule Do not refactor and add features at the same time - is probably less risky than both at once.
-- --
Ed Avis
ed@membled.com
Refactoring is crucial
by
_wintermute
·
· Score: 5, Insightful
~sigh~
Some of you people simply have NO idea how code works in the real world, i am sure of it. Hacking perl scripts is so unlike developing the large OO software that drives most information systems.
One of the fundamental issues with software architecture is that more often than not architecture is emergent. 'build one to throw away' is an old old adage (I believe it was Brooks who orginally declared this) and neatly summarises the key problem with developing software architecture.
"Even when one has the time and inclination to take architectural concerns into account, one's experience, or lack thereof, with the domain can limit the degree of architectural sophistication that can be brought to a system, particularly early in its evolution." From the Big Ball of Mud (link below).
We design, we develop, we learn, and then we design again... the sceondary design phase can be called refactoring. There are a number of refactoring patterns (I recomend the 'Refactoring' book) and some of the coolest Java IDEs support refactoring (check IDEA and Eclipse) - you can do things like move methods up the object hierarchy into base/parent/super classes, extract methods from bodies of code, change names, merge classes etc etc). These features let the savvy developer leverage the emergent aspects of design. Driven by time/cost/deadlines, we often do the thing that works rather than the thing that works elgantly. Refactoring lets us recapture some of the elgance of our code. Coupled with test-first methods, we have an incredibly powerful system.
Pretty much ALL modern software lifecycle models are iterative, simply because up front design does not work. The waterfall model is a naive concept of a bygone era.
Refactoring is therefore a crucial aspect of an efficient design process. Typically, I would suggest that refactoring occurs at the end or begginning of each iteration... our refactoring is informed by the evolution of the software - we don't refactor for fun, we clean up code SPECIFCALLY to target aspects of the product we know will change or
To see refactoring in action, join an Open Source project. Most OS teams that I have witnessed in action will employ refactoring of some description, even if they don't call it that. It makes a great deal of sense in OS, because we have large, distributed teams working on software, refactoring helps consolidate changes by disparate team members.
further reading: http://www.laputan.org/mud/
-- technoshamanic resistance within hyper-transgressive ontology
Design Patterns
by
jtdubs
·
· Score: 5, Interesting
Everyone all hopped up on Design Patterns that has any background in high-level programming needs to read:
Revenge of the Nerds, by Paul Graham http://www.paulgraham.com/icad.html
Paul Graham is a Lisp guru, among other things. His perspective on "patterns" is quite in contrast to that of the XP fab four.
Specifically, I refer to this fabulous quote:
"If you try to solve a hard problem, the question is not whether you will use a powerful enough language, but whether you will (a) use a powerful language, (b) write a de facto interpreter for one, or (c) yourself become a human compiler for one. We see this already begining to happen in the Python example, where we are in effect simulating the code that a compiler would generate to implement a lexical variable.
"This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough -- often that I'm generating by hand the expansions of some macro that I need to write."
Slashdot Mirror
Sex - Find It
What bothers me, is that the process being plugged here doesn't address methods for keeping all of the expressions of the program consistent. Tests are a (limited) alternate expression of the program's functionality that are trivial to compare to the original. Yes, they need to be good. What about documentation (which I define separately from annotated indexing, such as doxygen or Javadoc produce), which is another, separate expression (usually not in an executable language) of the program?
Until these authors address how to keep the entire structure from docs down to code consistent during a refactoring I think they are missing an important point. I've pointed this way before on Slashdot, but the only good way I've found for ensuring that non-executable forms of the program are consistent with executable forms, is formal Software Inspection (see Gilb's stuff at Result Planning ). I've found that the more versions of the code there are (requirements, user docs, code itself, tests etc.) that are kept truly consistent, the more likely it is you will not make mistakes in the final expression (the code you ship).
The refactoring process can be even less "like walking a tightrope without a net"; you're net is a web built out of the relationship between all of these documents, not just the code and tests!
Pick up any Forth book from the early 1980s and a major theme is that of properly factoring your code. I was always surprised that no one ever picked up on the term--until the last several years, that is.
I think the point of refactoring is that it happens exactly when you add a new requirement. You have some code that does X. Now you have a requirement that it do Y as well. There is a clean way to add feature Y, but it would need restructuring the existing code first. So as a first step you refactor the code so it still does X - 'but better!' - and then you can add code to do Y more easily. Doing the two steps separately - the XP rule Do not refactor and add features at the same time - is probably less risky than both at once.
-- Ed Avis ed@membled.com
~sigh~
... the sceondary design phase can be called refactoring. There are a number of refactoring patterns (I recomend the 'Refactoring' book) and some of the coolest Java IDEs support refactoring (check IDEA and Eclipse) - you can do things like move methods up the object hierarchy into base/parent/super classes, extract methods from bodies of code, change names, merge classes etc etc). These features let the savvy developer leverage the emergent aspects of design. Driven by time/cost/deadlines, we often do the thing that works rather than the thing that works elgantly. Refactoring lets us recapture some of the elgance of our code. Coupled with test-first methods, we have an incredibly powerful system.
... our refactoring is informed by the evolution of the software - we don't refactor for fun, we clean up code SPECIFCALLY to target aspects of the product we know will change or
Some of you people simply have NO idea how code works in the real world, i am sure of it. Hacking perl scripts is so unlike developing the large OO software that drives most information systems.
One of the fundamental issues with software architecture is that more often than not architecture is emergent. 'build one to throw away' is an old old adage (I believe it was Brooks who orginally declared this) and neatly summarises the key problem with developing software architecture.
"Even when one has the time and inclination to take architectural concerns into account, one's experience, or lack thereof, with the domain can limit the degree of architectural sophistication that can be brought to a system, particularly early in its evolution." From the Big Ball of Mud (link below).
We design, we develop, we learn, and then we design again
Pretty much ALL modern software lifecycle models are iterative, simply because up front design does not work. The waterfall model is a naive concept of a bygone era.
Refactoring is therefore a crucial aspect of an efficient design process. Typically, I would suggest that refactoring occurs at the end or begginning of each iteration
To see refactoring in action, join an Open Source project. Most OS teams that I have witnessed in action will employ refactoring of some description, even if they don't call it that. It makes a great deal of sense in OS, because we have large, distributed teams working on software, refactoring helps consolidate changes by disparate team members.
further reading: http://www.laputan.org/mud/
technoshamanic resistance within hyper-transgressive ontology
Everyone all hopped up on Design Patterns that has any background in high-level programming needs to read:
:-)
Revenge of the Nerds, by Paul Graham
http://www.paulgraham.com/icad.html
Paul Graham is a Lisp guru, among other things. His perspective on "patterns" is quite in contrast to that of the XP fab four.
Specifically, I refer to this fabulous quote:
"If you try to solve a hard problem, the question is not whether you will use a powerful enough language, but whether you will (a) use a powerful language, (b) write a de facto interpreter for one, or (c) yourself become a human compiler for one. We see this already begining to happen in the Python example, where we are in effect simulating the code that a compiler would generate to implement a lexical variable.
"This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough -- often that I'm generating by hand the expansions of some macro that I need to write."
He's my hero.
Justin Dubs