Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re^2: On the fear of re-factoring code

by Cop
on Oct 06, 2007 at 02:26 UTC ( #643019=note: print w/replies, xml ) Need Help??


in reply to Re: On the fear of re-factoring code
in thread On the fear of re-factoring code

"I frequently refactor my code and legacy code."

This clearly smells bad design or no design at all. This is not brave.

Replies are listed 'Best First'.
Re^3: On the fear of re-factoring code
by erroneousBollock (Curate) on Oct 06, 2007 at 03:24 UTC
    "I frequently refactor my code and legacy code."

    This clearly smells bad design or no design at all. This is not brave.

    (emphasis is mine)

    Oh, how so? (I wouldn't want to make fun of your nose... it has obviously helped you to gauge the perceptions of other monks thus far.)

    (I apologise to other monks in advance for the length of this rant, but really Cop could do with a few examples to take his elitism down a few pegs).

    Your argument seems to be that I wouldn't need to refactor if bothered to design first, or if I applied a "good" design first.

    I can tell you that when I design software (or a library), I do so in a minimal (as little code as possible to meet the goals / tests), likely-to-be-robust (not using techniques that I've found to be brittle or which introduce too many dependencies) manner. Furthermore, I've inferred from your comments (when you're not busy trolling) that you do something similar.

    As I mentioned, I primarily refactor code for efficiency and/or for flexibility in reuse.

    I don't think that anyone would argue that it's a good idea to focus on low-level performance in one's initial design. Do I choose data-structures and algorithms that have performance characteristics known to be faster than some "naive" implementation?... absolutely, that's a benefit of higher education, experience and the bounty of Comp-Sci and Math literature available through the Internet.

    Similarly, it's not necessarily a good idea to focus on how the code can be re-used until it's clear that the solution works for all the unit tests and that the solution is generally robust. Doing so can lead to prematurely complicated code which is harder to debug should some test fail. As I've mentioned, once the tests do pass I perform some transformations and annotations on the code to declare the intent of data-flows and of important properties (eg: algorithmic invariants, re-entrancy, etc), and I make sure that further tests ensure those modifications/assertions are correct (without functional regression).

    Once done, those transformations, assertions and tests help greatly to make the process of refactoring (for ease of re-use) a simple (even fun) experience.

    I'm sure the vast majority of designers don't immediately think in terms of iterators, higher-order combinators or specific concurrency patterns when they initially design a solution. Those approaches can require the code to hold to certain properties and/or to be "shaped" in a particular fashion before being available to implementation. It's best to code for a simple (working) solution, then to refactor to make such tools available.

    Coming back to performance... sometimes it's not absolutely clear that some efficient data-structure or algorithm will match the requirements and dependencies of the problem space (but I may have a hunch). In those cases I prefer to solve the problem at hand in a minimal manner. I often find that once I've refactored the solution for ease-of-reuse that certain ordering dependences or problem constraints are no-longer applicable (eg: they may have been transformed from code to meta-data).

    In summary (notwithstanding your obviously impeccable sense of smell), the notion that design should preclude the need for systematic refactoring is one easily dispelled. Further assertion will not magically elevate it to truth.

    -David

      A reply falls below the community's threshold of quality. You may see it by logging in.
Re^3: On the fear of re-factoring code
by naikonta (Curate) on Oct 06, 2007 at 02:44 UTC
    "No design at all" is still one design strategy.

    Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://643019]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (1)
As of 2019-08-21 02:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?