Stop Refactoring!
Recorded at:
- Share
-
- |
Read later
My Reading List
Bio
Nat Pryce is author of "Growing Object-Oriented Software, Guided by Tests" and developer of the jMock mock-object library. He is an early adopter of XP, a contributor to several open source libraries and tools supporting TDD, and one of the organizers of the London XP Day conference. Pryce has received his PhD from Imperial College.
For the second time we are launching the GOTO Copenhagen conference in May 2012 after a successful execution in 2011. GOTO Aarhus has been an annual event in Denmark since 1996 and attracts more than 1200 participants (formerly known as JAOO). The target audience for GOTO conferences are software developers, IT architects and project managers.<a href="http://gotocon.com/">http://gotocon.com/</a>
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
The aim of refactoring is not perfection
by
Marcos Antonio
Interesting perspective
by
David Smith
1) class hierarchies don't conform to the Liskov sub-type ideal.
2) interfaces are too generic -- they should be small specific.
Just because a system has been heavily factored doesn't mean that it was refactored well.
The last comment you made about how the system in question was oriented towards a functional design. I have been an avid FP hobbyist for some time and have made it a point to learn enough Erlang, Haskell and Clojure to write some very pretty code. But I don't have enough experience to know how to properly design large business domain systems in those languages. I suspect if you concentrate too much on the high-order functions and not enough on the proper use of the polymorphic abstractions (type-classes, multi-methods, etc.) you will have problems.
In any case it was a thought provoking presentation. Thanks for sharing.
Quite a wishy-washy presentation
by
Conor Moran
However I have yet to work on this ideal, conceptually perfect, system. Most of the code I look at is often at entirely the other end of the spectrum.
As for the lead-in where he describes a guy making a system beautiful, and then discovering that the new feature is very difficult to add...more detail on that part is definitely needed. The presentation code be more concrete then.
For me it's probably like all aspects of life, balance is always good. Even for the health conscious, a little splurge every now and again might be just what the doctor ordered.
With design, there are always trade-offs, there is never perfection, simply suitability with specific qualities in mind (often in a circumstance where different/competing qualities are important).
It must be strong but look dainty.
It must be secure but fast.
It must be maintainable and adaptable. [Seems to me this is the one that Nat hits upon - for me refactoring is very much about maintainability, I guess he's arguing that it can inhibit adaptability. My "common sense" gut doesn't necessarily agree with that.]
Wabasabi objects are recognizable
by
Adam Nemeth
While our industry surely has the tendency to give up all sanity, and accept that we don't understand anything, I'm prone to account this for people who are too stupid to understand their own program, and work way beyond their actual cognitive borders, so called code-monkeys, mostly with no scientific background and are certainly limited by what kind of blog posts did they read as a substitute for books.
But someone with a PhD likely doesn't work beyond his cognitive borders and that software design is well within these bounds, so that isn't the issue here.
I'm yet to see a wabi-sabi object, which is multidimensional, multifunctional. I mean, yeah, a teapot can be weary, but it's still a teapot, and it's beauty lies behind the recognizability of being a teapot.
Now if you don't refactor, you'll have a class named Mud, which will act as a teapot, or worse, a class named Teapot, which will act as a building.
And that won't be wabi-sabi.
Of course, single-purpose enterprise applications are hard to find, but this doesn't apply to class-level: they can be, and they are usually a bit weary, yes, but in a good code, they usually still do their purpose in a recognizable way.
Alas, if they'd ever become hard to use, it's better not to have emotional bonds to them, and use it anyway (like wabi-sabi), but I guess it's better that in case they have too much shortcomings, we decide to get another one instead of them. Japanese do this anyway when not drinking tea, but using an automobil or such.
And that'd be refactoring, yes.
A system, is a system. A teapot is an element of a system, a full teaset to do a gong-fu cha consists of about 12 elements (and I don't know how muhc you'd need for a matcha ceremony). If any of the elements break, or they just can't fill their purpose anymore, we're likely to exchange them.
Oh, and btw, please: PHP devs DO argue a lot about how php-like their code is. Leave this out from your talk next time.
Dangerous
by
Bad Ninja
1) Recent college grads
2) Impatient programmers
3) Incompetent programmers
4) Programmers who are reluctant to evolve.
Don't give someone who's proven to do bad things a license to do bad things.
maybe it's refactoring too early that's bad
by
Bjorn Hansen
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think