Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Refactoring: Improving the Design of Existing Code

samzenpus posted more than 6 years ago | from the read-all-about-it dept.


kabz writes "Refactoring (as I'll refer to the book from here on in) is a heavy and beautifully produced 418 page hardback book. The author is a UK-based independent consultant who has worked on many large systems and has written several other books including UML-Distilled. Refactoring is a self-help book in the tradition of Code Complete by Steve McConnell. It defines its audience clearly as working programmers and provides a set of problems, a practical and easily followed set of remedies and a rationale for applying those techniques." Read below for the rest of Johnathan's review.Code refactoring is the process of restructuring code in a controlled way to improve the structure and clarity of code, whilst maintaining the meaning of the code being restructured. Many maintenance problems stem from poorly written code that has become overly complex, where objects are overly familiar with each other, and where solutions implemented expeditiously contribute to the software being hard to understand and hard to add features to.

Typically refactorings are applied over a testable or local scope, with existing behavior being preserved. Refactoring as defined in this book is not about fixing bad designs, but instead should be applied at lower levels.

Testing a la Extreme Programming is emphasized as a control for ensuring that program meaning is not changed by refactoring. It is not over emphasized, and this is not a book about testing, but it is often mentioned and stays in the background through the book.

The refactorings presented in the book are not intended as a comprehensive solution for all problems, but they do offer a means to regain control of software that has been implemented poorly, or where maintenance has been shown to simply replace old bugs with newer ones.

The book is divided into two main sections, introductory material that introduces and discusses refactorings, and a lengthy taxonomy of refactorings that includes both examples and further discussion. The introductory material consists of a long worked example through simple Java code that implements printing a statement for a video store. Despite the simplicity of the code, Fowler shows in clear detail where improvements can be made, and how those improvements make the code both impressively easy to understand, and easy to maintain and add features.

Several key refactorings are demonstrated in the opening chapter including Extract Method, Move Method and Replace Conditional with Polymorphism. This is a book about programming in the object oriented paradigm, so as you might expect, the first two refactorings refer to extracting and moving object methods either into new methods, or between objects. The third example provides a means to replace special cased behavior in a single object type by deriving a sub type of the object and moving type specific code to the sub types. This is a fundamental technique in object oriented programming, and is discussed here in practical terms.

Now that several actual refactorings have been introduced, Fowler provides a solid and well thought-out discussion of the why's, when's and when not's of refactoring. For example, code can decay as features are added, and programmers special-case, or bodge additional functionality into existing objects. Fowler argues that the bitrot and decay makes software more unreliable, leads to bugs and can accelerate as the problem gets worse. Faced with these problems, refactoring should be used to improve local design and clean up and improve code, leading to better software, that is easier to maintain, easier to debug, and easier to improve with new features as requirements change.

However, there is a caveat, in that since software functionality should remain unchanged during refactoring, the process of refactoring consumes resources, but provides no easily measurable value. Fowler confronts this issue in a section that discusses how to communicate with managers, that you are performing refactoring work. He denies being subversive, but his conclusion is that refactoring should essentially be folded in with normal work as it improves the overall result.

This is a bit like goofing off on the basis that you'll think better after 20 minutes of fooseball. I'd definitely subscribe to that theory, but many others may not.

Kent Beck guests in Chapter Three for a review of the issues in typical software that suggest a refactoring may be needed. This chapter is entitled Bad Smells in Code, and most of the smells presented will be familiar to any reasonably experienced programmer, and they will be a great learning experience for less experienced programmers. I got the same feeling reading this chapter as I did when I first read Code Complete. Here was someone writing down names and describing problems that I had a vague unease about, but was too inexperienced to really articulate or do something about. Typically the refactorings address the same kind of issues that a code review with a skilled experienced programmer would address. Long parameter lists, too long methods, objects delving about in each others private variables, case statements, related code spread across different objects etc. None of these problems are debilitating in themselves, but added up, they lead to software that can be prone to error and difficult to maintain.

Most of the remaining substance of the book, 209 pages, is given over to a taxonomy of refactorings. These 72 refactorings are covered in detail with comprehensive simple examples presented in Java. Each refactorings is given a clear name, a number and a line or two of descriptive text. The motivation for the refactoring is then discussed, often including caveats and cautions. The mechanics of implementing the refactoring are then listed, with 1 or more (and often more) examples of implementing the refactoring. Refactorings range from the very simple to more complex examples such as Convert Procedural Design to Objects.

Due to the difficulties of reproducing large and complex sections of code, Fowler sticks with relatively simple examples. These seem to grate on him more than the reader, and he can come across as somewhat embarrassed when we look at the employee, programmer, manager pay example for the tenth time. I certainly didn't have a problem with it though.

This is a very well written and fun to read book. I personally feel that much of the material is implied by from Code Complete, but Fowler does a fantastic job of expanding and formalizing the idea of applying explicit refactorings. Much like Code Complete gave a motivation for keeping code well commented and laid out, this book presents the case for care and feeding of how to structure software. To fight bitrot and technical debt, poorly structured and unclear code should be targeted and refactored to improve structure and clarity. This gives a very real payback in terms of less required maintenance, and ease in adding features later on down the line.

Despite the fact that all the examples are in Java, the ideas are easily transferable to C++ or any procedural object oriented language. I highly recommend this book.

You can purchase Refactoring: Improving the Design of Existing Code from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Sorry! There are no comments related to the filter you selected.

Awful description (5, Insightful)

Anonymous Coward | more than 6 years ago | (#21970802)

This is a bit like goofing off on the basis that you'll think better after 20 minutes of fooseball. I'd definitely subscribe to that theory, but many others may not.

It's not at all like that. If you really need an analogy to understand this very simple concept, it's like seeing that your desk is overflowing with paperwork and spending some time filing everything properly. A little time invested can make it a lot quicker to find what you are looking for and help you deal with one thing at a time.

Main problem with the book... (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21970986) was written by niggers

Re:Main problem with the book... (0)

Anonymous Coward | more than 6 years ago | (#21971948)

No, the main problem is that it was written by a fictional character in a soap opera.

Re:Awful description (1, Funny)

Anonymous Coward | more than 6 years ago | (#21971310)

Plus, this is Slashdot, so a bad analogy should involve a car somehow.

Re:Awful description (5, Insightful)

dubl-u (51156) | more than 6 years ago | (#21973092)

I agree that this is a terrible analogy:

This is a bit like goofing off on the basis that you'll think better after 20 minutes of fooseball. I'd definitely subscribe to that theory, but many others may not.

The analogy I usually draw is to cooking.

Everybody's thrown a big dinner party and then left the dishes for a few days. Or even worse, had a roommate who did. Turns out this sucks, because if you just want to make yourself a little breakfast, then it's harder to cook. You have to scrape out a pan and chip off a plate just to get started. And cooking is twice as much work because you have to shift the mess around just to get at the counter, and then shift it again to get at the stove.

Then when you're done, you sure aren't going to wash up properly; the sink's filled with dishes already. So you just toss your dishes on the top of the pile, saying you'll get to it "later". Of course, that ever-growing mound of fuzzy dishes is the real-world analogy of half the code bases I've seen. And the giant rewrites that inevitably follow are like tearing down your kitchen and building a new one because that's the cheapest way out of the mess.

Instead, good chefs work clean. They clean as they go. Always. Not because they're uptight freaks, but because if they don't, the mess slows them down and makes them sloppier, eventually resulting in a giant clusterfuck, with all their colleagues yelling at them.

Refactoring is just a way for programmers to clean as they go. I picked up the habit years ago, and now would never go back, as it's the fastest way I've found to get good work done.

Old news. (4, Informative)

Kaz Kylheku (1484) | more than 6 years ago | (#21970862)

Reviewed back in 1999 on Slashdot. []

Re:Old news. (1)

corby (56462) | more than 6 years ago | (#21971014)

That is ridiculously insensitive. Everybody knows that samzenpus is unfrozen from the year 1999 [] , and is struggling to regain his relevance as a critic.

Don't listen to Kaz, I'm behind you all the way, samzenpus. Hey, man, can you give us a sneak preview of that movie American Beauty? I hear it's a real sleeper!

Re:Old news. (3, Interesting)

$RANDOMLUSER (804576) | more than 6 years ago | (#21971088)

It is a really good book. It got me thinking about objects in ways that GoF never did. Maybe it's time to introduce a new generation of /.ers to it.

Re:Old news. (2, Funny)

The Ultimate Fartkno (756456) | more than 6 years ago | (#21971114)

Goblet of Fire was pretty awesome, but it's no Deathly Hallows.

Re:Old news. (4, Funny)

spleen_blender (949762) | more than 6 years ago | (#21971358)

I'm not really into Pokemon.

Re:Old news. (1)

hansamurai (907719) | more than 6 years ago | (#21971532)

Looks like the assigned score hasn't been refactored since then. I suppose that's a good sign the book is actually good and doesn't focus on specific technologies.

Re:Old news. (0)

Anonymous Coward | more than 6 years ago | (#21971852)

you must be new here. oh wait...!

Re:Old news. (1)

Blakey Rat (99501) | more than 6 years ago | (#21971996)

Also, it's spelled "Foozball." Since we're being critical and all.

Re:Old news. (1)

JerkBoB (7130) | more than 6 years ago | (#21972096)

Also, it's spelled "Foozball."

Fooseball. From Fußball, which is a shortening of Tischfußball.

Fuß == foot. ball == ball. Football (soccer, for us yanks).


Re:Old news. (0)

Anonymous Coward | more than 6 years ago | (#21972270)

Although the tabletop game (what I assume the review writer was referring to) is commonly spelled fusball [] .

Re:Old news. (1)

StarvingSE (875139) | more than 6 years ago | (#21972282)

Yes, this book has been out for a number of years now and is concept is not new. It is (or should) be taught in any decent software engineering curriculum.

What gets me is that this book was published back in 1999, yet there hasn't been that much progress in terms of automated refactoring tools since then. Most IDE's have a handful of the simple ones available, but nothing complicated such as extract class (which I use frequently and is prone to errors).

Change, we love it! (0)

Anonymous Coward | more than 6 years ago | (#21970870)

Typically refactorings are applied over a testable or local scope, with existing behavior being preserved.

IOW: Refactoring changes shit around without making a difference. Ever heard of "never touch a running system"? Especially if you expect it to do exactly the same after you're done with it?

Re:Change, we love it! (3, Interesting)

magical_mystery_meat (1042950) | more than 6 years ago | (#21971176)

If the application is "done" and no major components are to be added, then by all means leave it alone.

However, most systems aren't like that. They need to be changed due to changes in requirements, new functionality, business rules, etc., and that's where refactoring helps you - it helps isolate functionality and help the system evolve. (The app should have been designed with that in mind from the beginning, but you and I both know that it never is.)

The main problem I have with refactoring (both the book and the concept) is that it's way too easy to go overboard with it because it presents a Right Way of writing code. Sometimes methods need to be 20 lines, sometimes classes need to do more than one thing, sometimes inheritance just gets in the way. Fowler respects these ideas, but I've known people who read this book and take refactoring to its logical extreme, which results in overly fragmented code.

I also despise the XP directive to not comment code, which Fowler promotes.

In all it's a good book but it's best to read it when after you've had a few years of real world experience and you can tell what should and shouldn't be taken seriously.

Re:Change, we love it! (1)

mr_mischief (456295) | more than 6 years ago | (#21971436)

Even when you plan for expansion and extension, you usually plan for extension in the wrong direction. Changing business requirements, new users, and brilliant but unexpected new features often require changes to your plans for change (or extensions to your extension mechanism). Let's face it, breakthrough ideas that simply must be worked into a program aren't anticipated fully. That's what makes them breakthrough ideas.

Re:Change, we love it! (3, Insightful)

Peaker (72084) | more than 6 years ago | (#21972948)

I also despise the XP directive to not comment code, which Fowler promotes.
Consider the goal, not the means. The goal is documenting the code. Those who go against comments (me included) are not against documentation of the code. We are against documentation that may easily lose sync with the code, where better forms of documentation exist.

The other forms of documentation are meaningful names. If you want to document a sub-expression, which does not have a name, give it a name, by assigning it into a variable before using it. If a piece of code does not have a name, then give it a name by putting it in a separate function.

Variable and function names are much less likely to go out of sync with the meaning of the code than comments are, are more concise and less redundant (so they avoid violating the DRY principle).

Remember, bad/wrong documentation is worse than no documentation.

who doesn't know about Refactoring? (3, Interesting)

StandardDeviant (122674) | more than 6 years ago | (#21970880)

I don't mean to be a wet blanket, but the book has been out for quite some time -- checking Amazon, July of 1999. It is pretty great, and I would recommend it to those who somehow managed to miss it up to this point, but a review almost nine years later? Slow news day much?

On the other hand, maybe periodically prodding towards the direction of higher internal quality (to be distinguished from external quality, that which is perceived in a black-box fashion by your customers, the relationship between these two qualities is of course a matter of much friction and debate between the managing and laboring classes) isn't a bad call. Lord knows any extra ammo to convince people that this is worthwhile is appreciated. As much as we like to think of ourselves as poets, I sometimes think the traditional profession most software development resembles is "butcher" or "janitor", just one messy hack-job and sweep under the rug after another after four or five decades of which you can retire and grumble on the beach about putting cyanide in the guacamole, fondly reminiscing about your red swingline or asr-33 or what have you.

Re:who doesn't know about Refactoring? (2, Insightful)

gbjbaanb (229885) | more than 6 years ago | (#21971022)

I've just been reading a nice blog about how the modern world is chucking more and more stuff at us (yes, I'm looking at you Microsoft C#/.NET teams) so we barely have time to learn something before its obsoleted; cannot learn enough about all of the new features that are being pushed at us; stress out that we think we need to learn in order to keep up-to-date with modern development practices; etc.

This review comes as a pleasant reminder that you don't have to chuck your old code away and rewrite it all in the latest, coolest tech-fashion. Keep the old stuff working, refactor it so it can still be maintained, enjoy producing applications that your customer wants and that work well for your customer.

for example, I had a meeting with some of my american colleagues early this week where they wanted to "throw away all our old SQL access code and rewrite it all using LINQ". Please, lets not.

Re:who doesn't know about Refactoring? (1)

kevin_conaway (585204) | more than 6 years ago | (#21971718)

I don't mean to be a wet blanket, but the book has been out for quite some time -- checking Amazon, July of 1999. It is pretty great, and I would recommend it to those who somehow managed to miss it up to this point, but a review almost nine years later? Slow news day much?

I see where you're coming from but I think this book is so fundamental that the article will be worth it if one new person reads the book and takes its advice to heart.

The book is 9 years old and its concepts are still relevant and practical today. That says a lot about a tech book

Re:who doesn't know about Refactoring? (1)

j_edge (20712) | more than 6 years ago | (#21972344)

As a matter of fact I do tend to think of myself as a "janitor".. at least in my current position, when more than 1/2 my time is spent refactoring poorly-written code from CIS majors or techs who learned a language, got hired as a programmer and thought that's all that was needed in Software Development. No understanding of data structures, algorithms, etc.. much less more recent concepts like design patterns or unit testing. Feh!


Re:who doesn't know about Refactoring? (1, Funny)

Anonymous Coward | more than 6 years ago | (#21972420)

You are right. 418 pages of Bullshit for this... Select your code in Eclipse IDE, Go to Refactor Menu, and select Extract method, Extract interface, etc. Done! Must be some Agile/XP "guru" trying to show off!

How is this news? (0)

Anonymous Coward | more than 6 years ago | (#21970886)

The book came out in 1999, that's almost nine years ago. And yet, a review finally appears here. Well, at least the book was good, in the the Amazon reviews [] the average rating is almost five stars.

MakeWork (1)

iBod (534920) | more than 6 years ago | (#21970912)

How this can be compared to McConnell's epic(s) I don't know.

Re:MakeWork (1)

stg (43177) | more than 6 years ago | (#21971098)

I've read both - while Code Complete is pretty good too, I think Refactoring is a bit better, in a practical sense.

Re:MakeWork (1)

iBod (534920) | more than 6 years ago | (#21971452)

How is it better?

It seems to me like doing a quick makeover as opposed to getting it right the first time around.

In my experience, and I don't thing I'm a coding God or anything, most code is generated by idiots (or to be kind, people who just don't understand the task at hand).

If the design of an application is fubared from the start, you can't refine the mistakes out of the result.

You need to understand the application requirement and code correctly through the entire process. There's no going back.

Re:MakeWork (2, Funny)

chromatic (9471) | more than 6 years ago | (#21971998)

If the design of an application is fubared from the start, you can't refine the mistakes out of the result.

There's an interesting book you should read. I forget the name, but it's about how to improve the design of existing code.

Re:MakeWork (3, Informative)

stg (43177) | more than 6 years ago | (#21972196)

First - you do realize the 2nd edition of Code Complete has a whole chapter on Refactoring, right? AND it recommends the other book for more details?

Have you actually read the book or are you just going from the review? Most of the methods are designed to work in a very small scale.

Examples - have you...
- Moved some code in the middle of a method to a separate method to make your code clear or re-usable?
- Renamed a variable with an unclear name?
- Added an intermediate variable for a complex calculation?
- Moved a complex boolean expression into a well-named boolean function?
- Added/removed a parameter to/from an existing method?

These are all refactorings, although some of the simplest. You might say that is just common sense, but that is kind of the point of it, and the particular steps are designed so that you won't screw up the code with common mistakes. Many refactoring tools exist too, and they are quite useful - for example, when adding a parameter to a method, one of my refactoring tools show me where that was used and I can edit any with a click (and also note if they all need it, or if I should give it a default value). If I change the name of a method, it can replace everywhere it is used (a search and replace can do the same, except if another object has a method with the same name it will screw things up - so you have to watch each replace carefully).

You might also note that many refactorings match other concepts in Code Complete.

None of these are supposed to "fix" a broken design by itself. They are meant to slowly improve the code so that it is easier to keep working on it.

My coworkers are insane. (5, Funny)

RandoX (828285) | more than 6 years ago | (#21970916)

Does your book cover that?

See Chapter XII - 'Kill Them' (3, Funny)

iBod (534920) | more than 6 years ago | (#21970984)

And bury them deep.

Re:My coworkers are insane. (1)

Scrameustache (459504) | more than 6 years ago | (#21971262)

Does your book cover that?
"a heavy and beautifully produced 418 page hardback book."

Coworker's head, meet hardcover book...

Java-Specific (1, Interesting)

justasecond (789358) | more than 6 years ago | (#21970950)

One point about the review: The note about the examples being transferrable to C++, etc. is a little off; some of the refactor techniques are basically workarounds for Java quirks. In fact, I've always felt that the book should have been called "Refactoring: Improving the Design of Existing Java Code".

Not a bad read overall, but it could have been made better by presenting examples in different languages, a la the GOF Design Patterns book.

Re:Java-Specific (1)

nanter (613346) | more than 6 years ago | (#21971086)

The GOF Design Patterns book didn't present examples in multiple languages either. Its patterns were consistently universally applicable, though, I'll give you that.

Re:Java-Specific (3, Informative)

cyberkreiger (463962) | more than 6 years ago | (#21971356)

It presented examples in Smalltalk and C++.

Re:Java-Specific (1, Informative)

Anonymous Coward | more than 6 years ago | (#21971926)

GoF presents examples in both SmallTalk and C++, and most of the patterns are not directly applicable to C++, in the sense that if you just implement them as-written terrible things will happen.

An obvious example of this is the publish/subscribe (Observer) pattern. I once worked with an incompetent developer who had the fixed belief that you could just take GoF examples and use them without modification. So he did, and the first time an observer removed itself from the subscriber list during a notification call his crappy code fell over due to an invalid iterator. And then there were the fun things that happened when any subscriber threw an exception during notification...

The GoF patterns are excellent, and any good developer should know and use them. But simply taking them verbatim out of the book without thinking at least a little about language-specific implementation issues can land you in a big, hard-to-debug mess. No amount of rote copying will ever replace actual competency.

Love refactoring but primary problem is legal (4, Interesting)

Maxo-Texas (864189) | more than 6 years ago | (#21970994)

"new" code is a capital investment and gets very high tax benefits.
"refactored" code is a pure cost.

I do a lot of refactoring but i always have to sneak it in under the cover of a "new" project instead of a "bug fix" project.

Re:Love refactoring but primary problem is legal (2, Interesting)

Surt (22457) | more than 6 years ago | (#21971404)

Refactored code is new code to do an existing job. Does Microsoft not get to write down its investment in each new version of windows because it does the same job?

Re:Love refactoring but primary problem is legal (1)

kevin_conaway (585204) | more than 6 years ago | (#21971570)

The primary problem is not legal, but your management.

Improving your software is always a benefit, whether that benefit is visible to the customer or not is an exercise for your management to handle. By improving your code, you make it easier to maintain which in turn allows more NEW features to be added to it with less headaches.

Re:Love refactoring but primary problem is legal (2, Interesting)

Maxo-Texas (864189) | more than 6 years ago | (#21972728)

I do not think any of you guys got my point so I'll clarify.

From here: []
The entrepreneurial owner of a growing business would like to expand into other cities and states, but is hesitant. He does not believe his current accounting software will be able to handle the increased transaction load and produce the type of management reports he needs to make effective decisions, and the cost of the next tier software has always been a little out of reach. Under the 2003 Act, the business could expense the first $100,000 of the cost of the next tier accounting software and could immediately save $34,000 in taxes, using a 34% tax rate.

In other words, "new" software is 2/3 the price of the same code done as maintenance code.
So the ROI on your 100,000 maintenance change must be at least 34,000 to be equally justified to replacing the code with a new 100,000 project.

I know that there are huge benefits to refactoring code- but there are huge tax advantages (that translate to large real amounts of money) to writing it new.

Re:Love refactoring but primary problem is legal (4, Insightful)

cbcanb (237883) | more than 6 years ago | (#21971984)

Not true. not true.

Refactoring code is like paying off debt. When you add new code without thinking about the design, the internal quality goes down. This makes the code harder (read "more expensive", "slower", etc) to work with in the future. And since most of the cost of software is in maintenance rather than the initial development, that's a bigger issue than you think.

Carrying a little bit of technical debt is inevitable, and a good thing. But if you allow too much to build up (by not refactoring debt-heavy areas of code), the interest payments can become crippling. Your code sucks, you can't understand it, and making changes takes far more work than they should. That directly impacts the bottom line.

Re:Love refactoring but primary problem is legal (2, Interesting)

dubl-u (51156) | more than 6 years ago | (#21973184)

Refactoring code is like paying off debt.

Agreed! And that's the best way to explain it to execs.

On a new project, you refactor to keep debt low. On a legacy project, you refactor to keep "interest" costs low. The interest on technical debt comes out as less reliable systems, buggier code, increased maintenance cost, and higher costs for new features. All of those cost cash money, which in my experience is a lot more money than you'd pay to do things right.

Jazz can't be taught (1, Troll)

Daniel Phillips (238627) | more than 6 years ago | (#21971002)

At one time not so long ago the common wisdom was, jazz can't be taught, it is just something you have in you or not. Today, jazz is commonly taught by formal methods at schools like Julliard, producing many fine studio and live jazz musicians. So much for common wisdom.

Today, in computer science, it is commonly thought that there are star developers and there are normal developers, and that being a star developer is just something you have in you. Well. It smells like deja vu all over again.

Not quite the same (3, Insightful)

Moraelin (679338) | more than 6 years ago | (#21971406)

The fallacy you're doing there is shifting the scales in that comparison. One side is learning Jazz at all, the other is being a _star_ in programming.

You'll find that being a star in _any_ discipline, Jazz included, isn't just a matter of being given a crash course in music notation. There are many who can learn Jazz, but there are few which are stars at it.

And there are a ton of people who just aren't any good at Jazz, no matter how much you teach them. There are those who are born tone deaf, or lack the coordination, or those who just aren't interested in a musical career, or those who find that learning uber-boring, or a dozen other cases which you just can't turn into _stars_ in any kind of music.

I'll further go and say that in Jazz (or any other kind of music) it's a relatively low pay career and with very few oportunity to become a super-star. So I'd wager that any music school gets an already filtered set of candidates. It's already those who love that genre, are sure that that's what they want to do, etc. It's already the people passionate and motivated.

In programming, we get a ton of drooling burger-flippers who think they can just get a quick training in Java and earn the big bucks. Not because they like it, not because it fits their personality type, not because they showed any kind of aptitude or inclination, just because they think they can fake their way to the big bucks. And it shows.

If you want a more apt comparison, compare them to the gang wanting to be a rock star in high school and college. The prospect of glamour and big bucks is there, and every other high-school boy wants to be in a rock band. The problem is that most suck, and will _never_ be even an acceptable player with any instrument. And aren't particularly motivated to train hard either. How many actually become a _star_? I'll say that's lost in the decimals.

So basically to sum up the comparison to Jazz:

1. Yes, you can teach Jazz. You can teach CS too. That's why we have that kind of colleges, you know.

2. You can't just take any guy off the street and turn him into a _star_ musician. If you went and took random people laid off by McDonald and tried to turn them into musicians, very few would even make an acceptable musician, and _extremely_ few will ever be considerable a _star_. Same as programming.

But, of course, that won't stop idiot PHBs from trying.

Re:Jazz can't be taught (1)

rk (6314) | more than 6 years ago | (#21971416)

I agree with what you're saying, but it's not like anyone studies jazz because they can get a steady career out of it with a regular paycheck, health care, and a 401k. My wild-ass guess is there is a higher percentage of people studying jazz at music conservatories because they love it than we will find studying programming and software engineering. There are many people in software development because they perceived it as a good steady career. It doesn't mean that they can't be competent or even great at it, but someone who does something because they have a love for it is more likely (though not certainly) to be more knowledgeable, productive and capable.

Put another way, I'd guess that there are more software engineers who really want to be jazz musicians than jazz musicians who really want to be software engineers. Though I do love what I do for a living, I know I'm one of them. :-) (Un)fortunately, I'm a better engineer than I am a musician.

Re:Jazz can't be taught (1)

slim-t (578136) | more than 6 years ago | (#21971916)

Jazz is simple, you must be thinking of the Blues. The Blues must be a part of you, unless you sell [] your soul to the devil. God [] is the ultimate bluesman, of course.

Another Excellent Book, The Pragmatic Programmer: (3, Insightful)

lyapunov (241045) | more than 6 years ago | (#21971008)

THe Pragmatics Programmer: From Journeyman to Master" was published as well in 1999 and is written by Andrew Hunt and David Thomas. I just got it for Christmas and have been enthralled with it. They spend some time dealing with the refactoring of code as well as wonderul insight into a wealth of other areas.

This is yet another book that I wish I had read years ago. Working a few years in industry really makes you realize how much you can learn from other people. But alas, the problem of youth is that you always think you're the exception.

Re:Another Excellent Book, The Pragmatic Programme (1)

EricR86 (1144023) | more than 6 years ago | (#21971124)

I just got it for Christmas and have been enthralled with it.

That's actually a dead-on seconded from me.
Only because of slashdot, can I feel slightly less ashamed :)

A problem with 'refactoring' (4, Interesting)

w3woody (44457) | more than 6 years ago | (#21971052)

At several places where I worked management was always happy to allow cycles to be spent on the process of 'refactoring' the code.

Unfortunately, in my experience, the process of 'refactoring' involved making code more complex by adding to it. In one case, I saw the product of the 'refactoring' process wrap two pieces of functionality into two separate EJBs (with a whole 'dto-pojo' conversion scheme for data "isolation"). In another, I saw some functionality wrapped into a collection of beans--which was later wrapped in another layer of beans, and so forth, until 20 lines of code which set up a call into the javax.xml.translate package (for performing an XSLT transformation) into something like 8 bean layers. The 20 lines of code was at the heart of an 8-layer onion, each layer added by someone else's "refactoring" operation.

In Java, because modern IDEs allow you to write code without thinking, the problem with code is not that there isn't enough code (to prevent incestuous classes from being overly familiar with each other), but that there is too much code as programmers unfamiliar with the problem decided to add beans and interprocess communication and multiple threads without properly sizing the problem. (Right now I'm looking at an internal system which may need to process 1 transaction a second, tops, built in an inter-cooperating network of 8 EJBs, which someone thought would help improve transactional performance. Eight? A second system essentially replicates an in-memory SQL system rolled in-house: the system has been buggy because the reverse index processing had a race condition. Um, why wasn't that built in a dozen classes on top of MySQL instead of built with a couple of hundred classes that reinvent the wheel poorly?)

While I'm glad someone wrote a book on refactoring methodology, in my experience what we need is a book which describes how to write "simple" code: code that is just as complicated as it needs to be, and no more. And a book which also describes how to simplify overly-complicated code, how to pick simpler techniques, and how to manage programmers who have an "itch" so they go scratch it somewhere else--I think that would be a much more useful book.

It's easy to add complexity. It's hard to simplify.

Re:A problem with 'refactoring' (0)

Anonymous Coward | more than 6 years ago | (#21971164)

code that is just as complicated as it needs to be, and no more

As long as there are code metrics like LOC, that will not happen. Overengineered code is the standard, even in popular open source projects, because creating byzantine frameworks is easier than writing elegant and efficient code, and people won't appreciate your work if it looks easy (and elegant code usually has this "why didn't I think of it, it's so simple" quality.)

Re:A problem with 'refactoring' (1)

kevin_conaway (585204) | more than 6 years ago | (#21971636)

While I'm glad someone wrote a book on refactoring methodology, in my experience what we need is a book which describes how to write "simple" code: code that is just as complicated as it needs to be, and no more. And a book which also describes how to simplify overly-complicated code, how to pick simpler techniques, and how to manage programmers who have an "itch" so they go scratch it somewhere else--I think that would be a much more useful book. It's easy to add complexity. It's hard to simplify.

If you read the book, you'll find that Mr. Fowler agrees with you.

Read the TDD book by Beck. In it, he describes that TDD methodology in terms of making the code simple in terms of doing only what it should and no more.

Re:A problem with 'refactoring' (1)

Bob9113 (14996) | more than 6 years ago | (#21971674)

While I'm glad someone wrote a book on refactoring methodology, in my experience what we need is a book which describes how to write "simple" code: code that is just as complicated as it needs to be, and no more.

Your point has much merit. Bear in mind, though, that refactoring is intended to facilitate the redesign of active code. While the book you mention would have value, it doesn't mean refactoring is somehow less valuable. Refactoring teaches a good designer how to steer poorly designed code, it would be a different book that would teach good design.

It's easy to add complexity. It's hard to simplify.

And that's the key to the refactoring book. In my eyes (and apparently yours), good design often implies reducing complexity. And good design is hard. But even assuming you see a truly better design option, it is also hard to shift existing code with reasonable cost and risk. This book deals with the latter issue.

Method and outcome can sometimes be separate problems, treated separately. Refactoring is a method which does not necessarily imply that the outcome will be good.

That's a problem with java (1)

johannesg (664142) | more than 6 years ago | (#21972488)

...and not with refactoring. Whenever I come across java code it always seems needlessly complex, with endless layers upon layers, unneeded abstractions, and patterns applied far beyond what would make for useful architecture.

Before you start flaming, I'd like to state that this is probably more a problem with java *programmers* than with the language itself, although its design has certainly caused too many people to follow down that path. So the language is probably ok, but the surrounding libraries and the attitude and inexperience of many of its users are the real problem.

Donning asbestos underwear... Now!

Re:A problem with 'refactoring' (3, Insightful)

computational super (740265) | more than 6 years ago | (#21973038)

Amen. I'm getting to the point these days where I'm slowly becoming wary of anything that appears, to me, to be a good idea. In the mid-90's or so, I came across this new paradigm called "Object Oriented Programming". At the time, I was maintaining monolithic Cobol systems, and the appeal of OO was intuitive. I saw right away how it could be used to simplify code reuse, or even make reusable code that had not previously been reusable.

These days, OO means every function is encapsulated in a class, and every class has an ISomething interface, a SomethingImpl implementation (which has no data members) and an AbstractSomething base class (that's not extended by anything else), and a SomethingFactory that creates instances of SomethingImpl's and hands back a pointer to an ISomething... and if you ever float the concept of implementing ISomething again (you know, taking advantage of all that framework?), you'll be scolded for violating the purity of the OO design.

XP was another thing that, when I first saw it, looked like a great idea. It seemed to me that XP was essentially a description of what productive programmers were already doing while they were pretending that Gantt charts were meaningful and that project managers were useful.

Now XP is called "Agile" and companies hire "Agile Mentors" to show us how to do precisely the meaningless project management exercises that XP was meant to replace... When I see how much paperwork I have to fill out to be "agile", I long for the days of Gantt charts and Microsoft project.

Refactoring, too. When I first saw Fowler's book, it was like a lightning bolt. The intro talks about how he spent a few days at a client site "cleaning up" a bit of code to simplify his next task. I had had that same experience too many times to count - I had been tasked with, say, implementing lot tracking in an inventory system. It was obvious (to me) that if I first made some modifications to the existing system, I could insert the desired feature without disturbing everything else - but I could never seem to explain that to a nonprogramming manager (in the end, I always ended up doing it and pretending I hadn't because I didn't want to be responsible for breaking the entire thing). And here was a book dedicated to the technique!

Yet, nowadays, refactoring seems to mean going through working code and wrapping every function in a SomethingImpl class, giving it an ISomething interface, letting it extend an AbstractSomething base, and creating a SomethingFactory to create SomethingImpls...

Re:A problem with 'refactoring' (1)

dubl-u (51156) | more than 6 years ago | (#21973330)

It's easy to add complexity. It's hard to simplify.

Something where Refactoring's author, Martin Fowler, agrees strongly with you [] .

A lot of what you described isn't refactoring, which is defined as making design improvements that don't change behavior. Instead, those guys were just doing developer goldplating.

I think if you read the book, you'll see how a lot of the techniques in Refactoring are intended to be used in the service of simplification.

Code refactoring is the process of... (0)

iBod (534920) | more than 6 years ago | (#21971084)

...breaking working code!

By all means refactor the code you're working on but please leave working production code alone!

Why refactor?

1) Too much time on your hands
2) Big Ego - you can do what the original programmer did better
3) Someone has a ton of money to waste and some of it is on programming

I've seen refactoring in action - Boy! have I seen it!!

Re:Code refactoring is the process of... (1)

Dan667 (564390) | more than 6 years ago | (#21971276)

Actually, if you are in a situation like mine and take the 20 2k line block of code that are sprinkled all over the place and tweaked into one refactored lib that all these apps can use, your work load goes down considerably. Refactoring is a very good idea when you have maint problems.

Re:Code refactoring is the process of... (1)

iBod (534920) | more than 6 years ago | (#21971354)


Yes, but that's more like encapsulation than refactoring.

I totally agree that complex functions should be contained in a 'black box' with well-defined interfaces (like your big 202k block of code).

Re:Code refactoring is the process of... (1)

cromar (1103585) | more than 6 years ago | (#21971580)

You took the words right out of my mouth. I have refactored a lot of the last coder's projects because the code just sucked balls. (It really did - only a little ego involved :) Now I have hardly anything to do at work and my (non-coder) colleagues wonder why there are so few errors reported now!

Re:Code refactoring is the process of... (1)

iBod (534920) | more than 6 years ago | (#21971644)

Do you mean by that that your refactoring reduced reportable errors? I so, I salute you Sir!

Thing is, REFACTORING should exactly replicate the original, bugs and all.

Re:Code refactoring is the process of... (1)

dgatwood (11270) | more than 6 years ago | (#21972616)

Yeah, well, replicating the bugs is usually not a virtue unless you have to maintain compatibility with somebody else's code that you can't change. My refactoring work frequently reduces bugs in the code as well. The reason for that is that 99% of the refactoring that is worthwhile consists of consolidating nearly identical code into a single copy with special case code where needed.

It's often the case that software has special case behavior for... say a dozen very similar tasks. If you refactor those almost identical twenty versions of that function (the twelve versions you knew about plus the eight versions every previous coder missed because the word "process" had a capital 'P' in eight of the function names) into a single version of a function with special case logic, you A. reduce the number of places you have to change when you add a feature or fix a bug that affects all of those functions, B. significantly reduce the odds of forgetting to change one of them when adding features or fixing bugs, and C. almost invariably find places where the functions unintentionally differed in behavior slightly, generally as a result of missing one version of the function in prior feature additions or bug fixes.

I've found that this redundancy tends to happen far more in object-oriented programming than in procedural programming. I think that this is because programmers often override entire methods in the superclass without bothering to break out the minimum portions with variant behavior into their own methods. In procedural programming, by contrast, the tendency is to modify the existing function, though in some cases, I've still seen multiple copies of near-identical functions. *sigh*

In any case, whenever you increase code reuse through refactoring, you almost invariably reduce existing bugs and reduce the odds of new bugs creeping in. With the exception of cases where it reduces code volume, though, I wouldn't generally recommend refactoring a working app.

Re:Code refactoring is the process of... (1)

iBod (534920) | more than 6 years ago | (#21972738)

Yes I know that replicating bugs is not a virtue, but strictly speaking, refactoring should neither introduce bugs nor eliminate them.

Re:Code refactoring is the process of... (2, Insightful)

A beautiful mind (821714) | more than 6 years ago | (#21971476)

I have seen refactoring in action aswell.

It decreased the size of the program code, made the code more modular, faster, made possible to write good unit tests for it and decrease bug count per LOC, all in all rewarding the developer and user with a more stable, smaller, faster and more maintainable codebase.

Re:Code refactoring is the process of... (1)

iBod (534920) | more than 6 years ago | (#21971526)

You were most fortunate, and no doubt you were the guy doing the refactoring in question.

Stick around a while and see what happens when some asshat 'refactors' your code and you are called in to clean up the mess.

Re:Code refactoring is the process of... (1)

Surt (22457) | more than 6 years ago | (#21971484)

Where I work, we refactor only when fixing a bug, and since we have tests of everything that works in production code, you're guaranteed not to break anything.

There are frequently situations where an improved utility/helper class can handle a task that is currently re-implemented in the class you are editing. Removing duplicate code reduces bugs.

Re:Code refactoring is the process of... (2, Insightful)

Anonymous Coward | more than 6 years ago | (#21971518)

Two great reasons to refactor:

(1) Your requirements have changed.
(2) You are dealing with a piece of buggy code that is a nightmare to debug and test.

Refactoring sucks (4, Insightful)

Hal_Porter (817932) | more than 6 years ago | (#21971108)

I've worked at a load of places where there's insufficient resources to do things that customers actually want, but an endless program to refactor away the ugliness of code. And the thing is, it's bullshit. Customers don't care how ugly the code is, so long as it works. And good programmers can deal with ugly code [] - it's just the sort of people who are obsessed with refactoring that can't. So next time you find a thousand line function, or code full of #ifdefs ask yourself how much of that complexity is there because some customer demanded it. Will your rewritten 'pretty' version duplicate all features that the ugly version has? Do you even understand which ones are features and which ones are bugs? If so, why do you want to refactor it? And if not, how can you expect to get it right first time and not provoke howls of protest from the people that use it.

And if anyone whines about how old code needs to be rewritten, point them at this []

Old code doesn't rust, it gets better, as bugs are fixed. Lou Montulli again: "I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked."
That's just in a PC application. Try refactoring the 'ugliness' out of an embedded system and see how long your employer still has customers, and how long you still have a job. And it's interesting that evolution, an unconscious process that far outperforms human 'intelligent' designers doesn't have any concept of ugliness at all. Maybe that concept is just an artifact of your limited ability to deal with complexity.

Re:Refactoring sucks (1)

iBod (534920) | more than 6 years ago | (#21971248)

Absolutely Hal

The code that runs most of the world as we know it is pig-ugly. But it doesn't matter because it works, day-in, day-out. Now I'm not advocating ugly code (I try to make mine as pretty as I can) but the fact is, ugly code can be workable and efficient.

There seems to be a mindset here that only beautiful, elegant code can do the job. Not so!

Re:Refactoring sucks (0)

Anonymous Coward | more than 6 years ago | (#21971462)

Just wait till you have to fix the ugly code in a timely manner.

Especially if you didn't write the ugly code.

Then we'll see if you change your tune on ugly code.

Saving one hour of writing time isn't worth the hundred hours of extra maintenance time.

Re:Refactoring sucks (1)

Hal_Porter (817932) | more than 6 years ago | (#21971536)

You're missing the point, I'm advocating writing ugly code. I'm talking about code that has become complex through years of bug fixes and feature additions. That code is very valuable to the company that owns it. It's a compressed solution to problems customers have complained about its life. Refactoring throws away most of that.

Re:Refactoring sucks (1)

iBod (534920) | more than 6 years ago | (#21971808)

I've fixed plenty of ugly code in my time - and learned from it too.

Rather that turning my nose up at it, I tried to understand the intention of the original programmer. Sometimes I learned a trick or two.

Re:Refactoring sucks (1)

mr_mischief (456295) | more than 6 years ago | (#21971562)

That mindset happens, but that's not the idea of refactoring. The right mindset is that making your code more beautiful and more elegant before your next major functionality change will help with that. If you're not going to change anything other than the code layout, that's pretty silly.

If you inherit code that's laid out badly (even from yourself when you were tired or rushed) and need to fix a bug or add a feature, the time to clean it up plus fix the bug in the cleaner version might not be much more than tracking down and fixing the bug alone. It might even be faster if the poor code layout was harboring the bug spread across too many lines. Then, the next time you need to make a change, that section of code will be more tidy.

Doing whole programs just for the sake of cleaning them up is only meaningful for two reasons. One is to practice your refactoring. The other is if you're about to do an overhaul of the whole project and are likely to touch most of those parts. Otherwise, just refactor the parts you're going to change for your bugfix or new feature anyway.

Don't forget unit testing and project testing for continuity are important, either. If you're causing regressions when refactoring, you're doing something wrong.

Re:Refactoring sucks (1)

east coast (590680) | more than 6 years ago | (#21971434)

I've worked at a load of places where there's insufficient resources to do things that customers actually want

As a curiosity, do you mean the companies lack talent or is there some other reasons that they fall short?

Re:Refactoring sucks (1)

Hal_Porter (817932) | more than 6 years ago | (#21971574)

By resources I mean programmers. If the programmers spend all their time removing features from code, they won't be available to add them. Even worse, they might not want to anymore.

Re:Refactoring sucks (1)

halivar (535827) | more than 6 years ago | (#21971450)

The problem comes when the old code doesn't "just work," and you have to fix it. It's one thing to deal with code that has multiple paths for special cases; I'm talking about poorly designed, poorly documented, and poorly written code, with 8 years of patch-work for all the bugs in it. If the code is bad enough, if really is simpler to rewrite it than to figure out what is wrong with the spaghetti. I don't have time to waste on crap that, at some point in the future, is going to make me waste even more time.

I do a lot of maintenance work, and I've got a 5-strikes rule: if I have to revisit the same spaghetti 5 times to patch critical design flaws, I chuck it and rewrite it. So far, I have yet to regret this policy.

Re:Refactoring sucks (1)

Zet (178940) | more than 6 years ago | (#21971538)

Refactoring is not rewriting. If done correctly it preserves the semantics of
the original code. Code that has become unwieldy is broken; in my view the
ugliness and unmaintainability is itself a bug (even if it operates correctly).

Refactoring for "purity" is not an end in itself, it is a means to keeping
code readable and maintainable. The need to refactor needs to be weighed
against other engineering goals, including meeting near-term schedule

But it is a process that must be done to a certain degree, continually,
as code matures. It allows the actual underlying design to remain clear,
even as it evolves gradually in the face of features, bug fixes and fine

Dealing with complexity is a fact of life. Allowing unnecessary complexity
to fester is foolish.

Re:Refactoring sucks (4, Insightful)

rk (6314) | more than 6 years ago | (#21971654)

But that's not what refactoring really is. Refactoring is not about making code "purdy", it's about making it so it's easier to add those layers of bugfixes that all successful production systems have. What you're referring to is a bunch of lazy, vain chuckleheads who don't want to read code. Refactoring is noticing that an enhancement or bugfix that requires you to make a similar change in umpteen places in the code and working to make it so the next enhancement/fix to it doesn't take so much time in the future. Refactoring is noticing that venerable function with all the layers of complexity isn't even used anymore by anything (and KNOWING that, not just assuming it) and giving it a dignified retirement. It's not going through software like the Code Gestapo and looking for everything that doesn't conform to "The Right Thing As I See It."

PROTIP: Don't look to slashdot for advice (0)

Anonymous Coward | more than 6 years ago | (#21971656)

I mean really. It's not 1987 anymore

Re:Refactoring sucks (1)

kevin_conaway (585204) | more than 6 years ago | (#21971670)

You seem to be making the mistake of thinking that refactoring means "making ugly software prettier" when a closer meaning is "making bad software better"

Re:Refactoring sucks (5, Insightful)

Rycross (836649) | more than 6 years ago | (#21971672)

In the original article, Joel explicitly states that refactoring is fine and may even be needed. What he's opposed to is rewriting, which is an entirely different thing than refactoring (and, to disagree with Joel, may be completely necessary in certain fringe cases).

Good programmers can deal with ugly code, but if your code base takes two months to make a developer marginally productive and breaks in unpredictable ways from simple code changes, then you probably need to refactor. If you're spending tons of man hours treading water because the code is such an unbelievable mess that its nearly impossible to make a solid change without breaking something, then you're going to get better productivity if you bite the bullet and come up with a plan for refactoring.

Also, I always have to laugh at the whole "well a great developer can work with messy code..." Unless you're working in a small, tight team, its completely impossible to make sure that you're working with a good developer, much less a great one. A lot of developers out there are poor or average, and companies, despite their best efforts to avoid doing so, do hire these people.

Re:Refactoring sucks (1)

Fujisawa Sensei (207127) | more than 6 years ago | (#21971834)

Customers don't care how ugly the code is, so long as it works.

You've obviously never written a customer facing API.

And good programmers can deal with ugly code []

We "can" but I would rather not spend 8 hours grepping through trash, because some idiot used copy-paste coding rather than reusable functions and classes.

Re:Refactoring sucks (1)

starfishsystems (834319) | more than 6 years ago | (#21972574)

We "can" but I would rather not spend 8 hours grepping through trash

Yep. What the parent pretends not to get is that every software developer is posessed of finite cognitive bandwidth. You can expend that bandwidth on the mental bookkeeping necessary to make sense of trashy code, or you can put resources into cleaning up the code so that it is no longer a needless cognitive drain.

Furthermore, once cleaned up, the code stays cleaned up. The next developer to come along will not have to waste time making sense of bad code. Considering the stats on how much developer time goes into reading code written by others, refactoring and other forms of code cleanup is time well spent.

Of course, the code should have been well structured and readable to begin with, but even the best developers have their good days and bad days, and often good developers have to tolerate the product of mediocre developers. I just don't see the need to tolerate it more than once.

Re:Refactoring sucks (5, Insightful)

BagMan2 (112243) | more than 6 years ago | (#21971890)

There is no reason to refactor code that works and requires little to no maintenance. However, if you are working on a living code base, refactoring is critical to keeping things sane. I am not a fan of rewriting something just because it is ugly, but if ugly code requires significant modifications to support new functionality that is being added, then refactoring should be highly considered as part of the process. Hacking features into existing systems can be very time efficient in the short term, but almost without fail, the price paid is more difficult maintenance down the road, particularly if additional new features are to be added.

Obviously refactoring needs to be carefully considered on a case by case basis. How ugly will hacking in the new feature make the code? How likely is it that other new features will also be added to this code down the road? How many other programmers have to deal with this portion of the code? How much time do you have to make the change? How much work is it to refactor the code and do it the right way, versus just hack in the feature? These and many other questions need to be answered before one determines whether refactoring is a worthwhile effort.

As somebody who works primarily on server-software that is in a continuous state of changing and adding features, where stability is critical and expected lifetime is measured in decades, I personally have found that refactoring is almost always worthwhile in the end. I think the biggest problem with refactoring is not whether there is a need, but whether there is competence to get it done. Often times programmers will refactor something to work differently to their liking, but in reality will not have actually improved the flexibility of maintainability of the code at all.

Re:Refactoring sucks (1)

Marsell (16980) | more than 6 years ago | (#21972090)

Is this a general rant about some arbitrary definition of refactoring, or that advocated by the book?

If it's about the book, you haven't read it. One of the very first things it raises -- and repeats often -- is that you should have tests covering the functionality before refactoring. Guess why?

If you don't have good tests, jumping in and changing willy-nilly is idiotic.

Also, I should note that Joel's article mentions from scratch three times. How do you refactor a codebase from scratch exactly?

I suppose such (obvious) nuances are beyond the hoards of "I've worked at a load of places" Slashdot.

Re:Refactoring sucks (0)

Anonymous Coward | more than 6 years ago | (#21972238)

You are an idiot and the people who modded you up as insightful are idiots. Embedded software can be and is refactored. The only difference between refactoring embedded code and application code is that the constraints are different. This means that is takes someone with a brain and some education to refactor embedded code in such a way as to produce reliable and readable code. Your company should fire two of your bunch and hire a good programmer at 1.5 times the salary thus producing better code and saving money. idiot.

Re:Refactoring sucks (1)

brewstate (1018558) | more than 6 years ago | (#21973048)

After many years of code and fix (more code than fix) approach is applied to a project refactoring is sometimes the only thing you can do. Unless you want only a handful of programmers to be able to read it. I have hit so many problems with the my most recent refactor that I am amazed it even worked. For instance they had booleans in for loops to keep code out of embedded recursions instead of looping to call the code from another function. There were instances of goto points that were never hit and were kept active just in case. There were 4 forms that were used to hold 400+ global variables. It was, and to some degree still is a nightmare. Anyway what I am trying to say is refactoring is a necessary evil. It doesn't always have to do with egos. In our case one of our programmers moved on and he left the state of the program, over the course of 5-8 years, in a state of confusion. It is difficult to bring in a new programmer and get them to read something that the original author has difficulty reading. BTW the programmer was one of the owners so there wasn't a lot of checking up behind him.

Re:Refactoring sucks (1)

dcollins (135727) | more than 6 years ago | (#21973240)

"... it's interesting that evolution, an unconscious process that far outperforms human 'intelligent' designers..."

Won't agree with that. An interesting topic for debate or research, perhaps, but no way in hell can you toss that out like everyone automatically agrees with it.

Re:Refactoring sucks (0)

Anonymous Coward | more than 6 years ago | (#21973336)

Copy-paste is the best way to ensure the code looks uniform and tidy in all places. All text editors provide these features, and they are really useful! The 'refactor' shortcut does not even exist :-)

Nice to see (1)

coldtone (98189) | more than 6 years ago | (#21971542)

It's nice to see comments about the pitfalls of refactoring. (I'm sure it would be different on reddit :) ) In my experience it is very rare that any refactoring will actually improve an application.

The worst part of refactoring, it breaks merges.

Theory and Reality (1)

FromTheAir (938543) | more than 6 years ago | (#21971612)

There is a difference, and in any complex system, not your typical address database, you can only guess some of the design necessary to meet the requirements. The requirements are never complete because there is so much one does not know or discover until they try to do it and people use it.

Most clients I have dealt with are unable to define their own requirements properly, about all they can do is express their intentions and answer questions, they need to be guided

This is why I think design and development need to happen concurrently starting out with an intention, and various anticipated outputs and functionality that is needed.

One also needs to be comfortable with chaos and unknowing, while the design unfolds perfectly if one goes with the flow. The other thing that affects the quality of code is budget constraints and the egoic mind.

Polishing and improvement come after one figures out what they needed which only comes from doing.

WTF? (0)

Anonymous Coward | more than 6 years ago | (#21971666)

"Refactoring as defined in this book is not about fixing bad designs, but instead should be applied at lower levels."

Um. The title of the book is "Refactoring: Improving the Design of Existing Code"

So if it's not about improving bad designs, maybe the book should get a bad review, no?

Maybe it should have been called "Code Refactoring: Chewing the Staples Cause You Just Can't Let Sleeping Dogs Lie"

In any attempt at Refactoring, refactoring the design should be the first thing you consider, not the last.

Get it working -->(refactor design)-->Get it working right-->(refactor code)-->Get it working fast.

You might just find that as a side benefit of your redesign, a lot of crufty code gets pulled out by happy coincidence.

Fundamental Misunderstanding of Refactoring (1)

iBod (534920) | more than 6 years ago | (#21971710)

A lot of folks here just don't understand what 'REFACTORING' means.

Wikki says:

"A code refactoring is any change to a computer program's code which improves its readability or simplifies its structure without changing its results."

It has nothing to do with the size source code or the functionality of the program.

A properly refactored program will have the exact same characteristics and bugs as the original.

Kids nowadays!

Why all the negativity over refactoring? (1)

MobyDisk (75490) | more than 6 years ago | (#21971752)

I see lots of comments about how old code is solid and reliable and should not be refactored. This group must be working in a very different environment than the ones I am accustomed too. All too often, I come into a project where the same bugs keep re-asserting their heads over and over again, and they keep getting fixed over and over again. Usually, it is because the original code contains some routines that were copied and pasted over and over again, and by refactoring you take the best block of code and re-use it. The result is smaller, more readable, and less error-prone.

Wow! Now I'm All Fired Up and Ready to Refactor! (1)

aquatone282 (905179) | more than 6 years ago | (#21972110)

First project: Tony's nifty custom MS Access financial-tracking application!

First step: Rename all 122 tables from table1, table2, table3, etc to REAL names!

Martin Fowler is a self promotionalist (0)

Anonymous Coward | more than 6 years ago | (#21972210)

Martin Fowler isn't that smart if you listen to them, consultants are self promotionalists.

This particular book, despite being old, is full of a lot of stupid ideas.

For instance, that the refactoring process is, "move a line, see if this compiles, move a line, see if this compiles" as Fowler advocated at some lecture I went to in college.

Mechanically distilling things down like that is inane -- though XP is perhaps just as oddball and having Kent Beck and his pair programming absurdity on the author list does not bode well for anything.

Refactoring MVS (1)

iBod (534920) | more than 6 years ago | (#21972288)

Beautifying code is a subjective business.

I used to work for IBM on the MVS (now z/os) operating system. At the time it was all written in s/370 assembler, but got rewritten in PL/S (a cousin of PL/I but with lower-level functions like direct register/memory access).

I spent 3 years of my life (mid to late 80's) refactoring the MVS operating system. It was a mammoth exercise, and exacting too. There were 28 of us on the team, all top IBM sysprogs, based in the US (Armonk NY) and UK (Portsmouth). We had 5 IBM 3090-4 mainframes in various states of disaster while we carefully recreated decades of s/370 OS code.

It was a bit like archeology. You analyzed and pealed away layer after layer of BXLE and MVCL instructions (mostly uncommented) and tried to grasp what the original programmer's intention was. There was self-modifying code in some modules (changing a BR branch destination!) and some of the code was actually lost, and only available on microfiche!

Now that's refactoring!

Assembler Code Documentation (1)

Sanat (702) | more than 6 years ago | (#21972504)

I once had to take over the support of a series of 10,000 line assembler programs that did not have a single comment. these programs would communicate through the printer port with a black box device that was use for testing monitoring equipment.

Each different monitor had its own program so to make an across the board change to the codebase one had to change each program that was similar but different from the other.

I took a couple days out and first added comments and dividing lines as to what test was being run. This also involved figuring out what the code was even suppose to be doing at times.

This simple documentation task literally found hundreds of errors when comparing each individual test among that same test in all of the codebase.

The original code was written by an old professor in his 70's who was really sharp but never bothered to learn "C" so the code was written in assembler instead. As new monitors were added to be tested then the snapshot of the present code was modified and named for that monitor thus an ever growing quantity of code in various states of being updated was created.

documentation, standardization, refactoring all permitted this mess to be fixed. It actually was a fun project.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?