The Artima Developer Community
Articles | News | Weblogs | Books | Forums
Artima Forums | Articles | Weblogs | Java Answers | News
Sponsored Link •

Weblogs Forum
Prefactoring and Refactoring

23 replies on 2 pages. Most recent reply: Apr 26, 2006 9:33 PM by ken blau

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 23 replies on 2 pages [ « | 1 2 ]
Peter Hickman

Posts: 41
Nickname: peterhi
Registered: Mar, 2003

Re: Prefactoring and Refactoring Posted: Feb 9, 2006 3:01 PM
Reply to this message Reply
Advertisement
> I kind of see a lot of accepted design principles
> as ways of making code more easily fixed when the mistakes
> are inevitably discovered.

It is not just the mistakes that require code to be changed but the requirement of a function may change as the application grows.

Jonathan Gibbons

Posts: 2
Nickname: jonathan12
Registered: Feb, 2006

Re: Prefactoring and Refactoring Posted: Feb 10, 2006 6:54 AM
Reply to this message Reply
> 1. Agile development is just starting to become
> mainstream, so it's not "ancient", at all - it's more like
> "state of the art".

Some folks are only just getting into Rational - doesn't make it either mainstream or new. Agile has been doing the rounds in loads of projects for about 5 years now, which is about the life span of most methodologies before a new set of books starts taking them apart. I'm already seeing a few cracks.

> 2. Even if it was old, there's no reason to replace
> something, just because it's been around for a long time.

Yes there is. It's progress. The rate of change of change has to accelerate.

> Besides, "prefactoring", as it's described here, doesn't
> replace agile development.

I agree, but if you build on it you could rebrand/remix. Tension and conflict between methodologies is extremely healthy. It stimulates debate.

Jonathan

Mike Petry

Posts: 34
Nickname: mikepetry
Registered: Apr, 2005

Re: Prefactoring and Refactoring Posted: Feb 11, 2006 7:47 AM
Reply to this message Reply
Test Driven Design (TDD) has us "coding the simplest thing that works" or compiles for that matter. Once we get something working (or "green bar") we refactor the code into a form that promotes reuse and maintainability. We can confidently refactor because we have our test code serving as a safety net.
Therefore Prefactoring would have to be an alternative to TDD. The current alternative to TDD is "design up front" which is usually considered to be UML.
Prefactoring probably signals the realization that some forethought on the structure of code is probably a good thing. Strict "waterfall process" design up front is not a good idea but some up front design is a good thing.
Bottom line is there is no cook book approach to developing good software, however there are good ideas coming forth. The trick is how to use these methods, when to use them and how much to use them.
Ultimately it pays to have experienced smart people working on your projects, much to the chagrin of the bean counters.
btw I hate the use of cowboy as a derogatory term which is supposed to tag an undisciplined developer. I always thought cowboys where cool myself.

Richard Jonas

Posts: 147
Nickname: rjonas
Registered: Nov, 2005

Re: Prefactoring and Refactoring Posted: Feb 12, 2006 10:55 AM
Reply to this message Reply
Speak to users and use your experience to honestly understand the requirements that are likely to change and those that are not likely to change. You may not want to tell the users which of their requirements you think will change.

For requirements that are less likely to change, you should prefactor and think about their design in advance and how these requirements fit into the big picture. If you know things aren't going to change, a 3rd party component (even if you can’t alter it) might be appropriate.

For requirements that are likely to change, you should implement something quickly, get feedback, adapt it to the changing requirements and refactor as you adapt. You should make sure the technologies you use allow you to adapt, e.g. by using TDD or making sure any 3rd party components have the source code and are written in a language you are familiar with.

===
Richard Jonas
Blog: http://www.richardjonas.com/blog

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Prefactoring and Refactoring Posted: Feb 12, 2006 12:17 PM
Reply to this message Reply
> > 2. Even if it was old, there's no reason to replace
> > something, just because it's been around for a long
> time.
>
> Yes there is. It's progress. The rate of change of
> change has to accelerate.

I'm sorry, but this is no argument against what I said. Let me state it in a different way: There's no reason to change something, regardless of its age, if it's the best way we know.

Besides, why should the rate of change have to accelerate?

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Prefactoring and Refactoring Posted: Feb 13, 2006 2:34 AM
Reply to this message Reply
> > 1. Agile development is just starting to become
> > mainstream, so it's not "ancient", at all - it's more
> like
> > "state of the art".
>
> Some folks are only just getting into Rational - doesn't
> make it either mainstream or new. Agile has been doing
> the rounds in loads of projects for about 5 years now,
> which is about the life span of most methodologies before
> a new set of books starts taking them apart. I'm already
> seeing a few cracks.

Could you give any examples of the 'cracks' you are seeing. Agile methologies have have well documented criticisms write from the outset but your paragraph above implies new ones.

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: Prefactoring and Refactoring Posted: Feb 13, 2006 9:17 PM
Reply to this message Reply
> While I understand the value of the concept, I can't
> distinguish what's the novelty here, and why putting a new
> name to what *seems* like basic Agile/OOD practices.

I was given a copy of the book recently. I think it's excellent. It reminds me of the much heavier (physcially) Code Complete byu Steve McConnell, though its clearly more influenced by the OO, patterns, and agile writers.

Solomon said there is nothiung new under the sun - well novelty is overrated in programming books. This is a good read, has good ideas, and deserves a better rating than most of its peers.

damith rajapakse

Posts: 1
Nickname: damithc
Registered: Apr, 2006

Re: Prefactoring and Refactoring Posted: Apr 14, 2006 7:05 PM
Reply to this message Reply
Despite all these negative comments, I feel there's something in prefactoring (more at my blog http://damith.blogspot.com) and I'm looking forward to reading the book.

ken blau

Posts: 1
Nickname: kblau101
Registered: Apr, 2006

Re: Prefactoring and Refactoring Posted: Apr 26, 2006 9:33 PM
Reply to this message Reply
Ken Pugh includes quote:

"THINK INTERFACES, NOT INHERITANCE..."

Why does Ken's application code contain only an extremely small sampling of interface based programming? All I could find was a collection interface that was used as an interface type in a parameter that would call the interface collection add item method in the body.

Ken makes reference to the strategy pattern in his book with a nice example that doesn't seem to make it into his finished book application code.

Ken, how about writing an article on interface based programming.

Much appreciated for all your good work.
Ken Blau
ken.blau@cox.net

Flat View: This topic has 23 replies on 2 pages [ « | 1  2 ]
Topic: Prefactoring and Refactoring Previous Topic   Next Topic Topic: What Virtualization Means to Developers
Sponsored Links


Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use