Agile Attitudes- Agile Attitudes - Refactoring

[Ron Morsicato]

------------------------------------------------------------------------

Agile Attitudes
Volume 1, Issue 2                                      May 13, 2004
                  A free bi-weekly email newsletter
                         Brought to you by
                      Agile Rules consulting
                        www.agilerules.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Welcome to Agile Attitudes, a newsletter of ideas, insights and
technical tips that help people find better ways to develop
software. Feel free to share this with anyone - just be sure you
send or print the whole thing, including the copyright notice.

Directions for managing your subscription are below.

                          O><O><O><O><O><O
                          
                            Refactoring
                         by Ron Morsicato


   In the last (first) issue, Nancy V. spoke about the perils of
taking shortcuts in your code development. She left us with the
notion that your code has to be ready for the next feature. She
used the term "refactored" to describe the state the code should be
in to make it so.

   If you look at code development as the addition of features in
order to make a product worthwhile in the marketplace, you've only
ot it half right. The other thing you should be doing is making
your code capable of remaining worthwhile in the marketplace.  The
way you do this is by maintaining a solid, effective, clear and
uncomplicated code base. You achieve this by that thing we've
called "refactoring." The notion comes from mathematical factors.
An equation is factored so that it is in a state where it is most
easily understood. Thus "refactoring" is all about changing how a
code base is presented to programmers so that they can more
effectively and efficiently work with it.

   But just what is it that you do to refactor your code? If your
code is in good shape, if its been refactored all along, then often
it's not much effort. Basically, you ask yourself the question: Is
it still as simple as it can be, or did I do something when adding
the new feature that is making the code a bit less understandable,
a bit more complicated?

   A good way to answer this question is to look for a duplication
of effort somewhere. For in creating that redundancy, it's like
putting the same information in multiple places, a prescription for
disaster. The same thing goes for functionality. At first it may
seem like a good idea, but then you start seeing changes in one part
of a software system cause an unexpected behavior somewhere else,
a sure sign that you're on the path to unmanageable code.

   What if your code is not in such good shape? The answer here is to
start small, installing the discipline on your team. When they next
touch a portion of code, have them do a little refactoring. Start off
simple, eliminate a variable or create an abstract class. The bolder
they get, the more likely something else will break. To reduce the
risk of this going undetected, agile developers test the devil out of
their code, a subject for more than one future newsletters.

                          O><O><O><O><O><O
More articles on Agile software topics at http://www.agilerules.com
     Within our company we have a sub-specialty in embedded systems. 
     Our site has articles on embedded XP and we support a discussion
     list focused on the use of agile methods for building embedded 
     software. The list signup info is at
     http://www.xp-embedded.com/mailman/listinfo

                          O><O><O><O><O><O
If you enjoyed this issue or found it useful, forward it to a
     friend! Help spread the word about better ways to build software
     - invite your friends and colleagues to join our growing reader
     community at
     http://www.agilerules.com/mailman/listinfo/agileattitudes 
    
                          O><O><O><O><O><O
Looking for a speaker for your next corporate or society meeting?
     We present dynamic, informative programs on topics of interest 
     to managers and technical staff in their transition to more 
     flexible, robust ways to create software.

                          O><O><O><O><O><O
Want to reprint this issue in your company or society newsletter?
     For permission to reprint any of the articles, contact us at
     info at agilerules.com.

                          O><O><O><O><O><O
                         Public Appearances
Currently none are scheduled. 
     If you would like to receive an email as soon as we know of
     an event in the Boston area of interest to the agile software 
     community, you can sign up for the announcements list at 
     http://www.agilerules.com/mailman/listinfo/agileannounce

                          O><O><O><O><O><O
Your feedback is welcome! Send feedback to info at agilerules.com

To manage your subscription:
     http://www.agilerules.com/mailman/listinfo/agileattitudes

                          O><O><O><O><O><O
             Brought to you by Agile Rules consulting
               162 Marrett Road, Lexington MA 02421

                  Copyright (c) 2004 Agile Rules 
                        info at agilerules.com

                          O><O><O><O><O><O
Privacy notice: We will not release a subscriber's address to any
third party for any reason. This is a strictly opt-in newsletter.
No one is ever subscribed without their explicit request.


_______________________________________________
AgileAttitudes mailing list
AgileAttitudes at agilerules.com
http://www.agilerules.com/mailman/listinfo/agileattitudes