AgileAttitudes Article
 
 
 

Vol 01 Issue 02- Refactoring

  
 
Back to the list of articles 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@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@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@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@agilerules.com http://www.agilerules.com/mailman/listinfo/agileattitudes </plaintext> </td id="bodytable_r1_c3_body"> </tr id="bodytable_r1"> </table id="bodytable">