Advertisement

Constant Refactoring After Programming (If It Ain’t Broke, Fix It Anyway)

  • Matt Stephens
  • Doug Rosenberg

Keywords

Unit Test Sequence Diagram Live Data Design Documentation Agile Modeling 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Reference

  1. 1.
    Originally presented at UMLWor1d as part of Doug’s `Alice in Use Case Land“ keynote speech. The full text is available at http://www.iconixsw.com/aliceinusecaseland.html.
  2. 2.
    In XP, “code smell” is shorthand for a coder’s intuition of when code is in need of improvement.Google Scholar
  3. 3.
    Extremos often claim that XP helps to bring software in on schedule because they keep revising the schedule in each iteration—in other words, they have “schedule,” but “the schedule” doesn’t exist per se. And if the team encourages the customer to embrace scope creep, they can just keep adding features as they go, revising the schedule ad infinitum, until the project gets cancelled. More about this in Chapter 11.Google Scholar
  4. 4.
    In fact, XP’s practices could have been tailor-made for maintaining legacy systems (possibly because XP aims to put the project into “maintenance mode” as early as possible, as we discuss elsewhere).Google Scholar
  5. 5.
    Except, perhaps, for “Introduce Null Object,” in which an object that represents null is introduced so that null values don’t need to be given special consideration. This has a very limited application, because the whole point of “null” is that it is special, and therefore should be treated differently from non-null values. Introducing objects that represent null could be storing up trouble, allowing special cases to pass through your code unchecked.Google Scholar
  6. 6.
    The key point here being that you design the system in detail, leaving no stone unturned. Taking the right approach (following a logical design process, as we discuss in Chapter 8) can work wonders in uncovering design errors (or preventing them from occurring at all) before any production code has been written.Google Scholar
  7. 7.
    Steve McConnell, Rapid Development: Taming Wild Software Schedules ( Redmond, WA: Microsoft Press, 1996 ), p. 72.Google Scholar
  8. 8.
    Martin Fowler, Refactoring: Improving the Design of Existing Code ( New York, NY: Addison-Wesley, 1999 ), p. 359.Google Scholar
  9. 9.
    Ibid., p. 67.Google Scholar
  10. 10.
    In fact, suggesting that “it is no longer expensive to make the changes” isn’t circular, it’s just plain wrong. It’s an assertion made without proof—and it’s wrong.Google Scholar
  11. 11.
    Chet Hendrickson as quoted on the C2 Wild page Chrysler Comprehensive Compensation,http://c2.com/ cgi/wiki?ChryslerComprehensiveCompensation.
  12. 12.
    Rational’s Object Technology User Group, http://www.rational.com/support/usergroups/rose/otug.jsp.
  13. 13.
    Note, that does not mean less unit testing—we just rely on them less!Google Scholar
  14. 14.
    Alan Cooper, The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity ( Indianapolis, IN: Sams Publishing, 1999 ), p. 186.Google Scholar
  15. 15.
    Ron Jeffries, “Essential XP: Emergent Design,” http://www.xprogramming.com/xpmag/expEmergentDesign.htm, October 21, 2001.
  16. 16.
    This is also an XP practice—the source is self-documenting, so design = source code = documentation. When all you’ve got is a hammer…Google Scholar
  17. 17.
    Doug Rosenberg and Kendall Scott, Use Case Driven Object Modeling with UML: A Practical Approach ( New York, NY: Addison-Wesley, 1999 ).Google Scholar
  18. 18.
    Doug Rosenberg and Kendall Scott, Applying Use Case Driven Object Modeling With UML ( NewYork, NY: Addison-Wesley, 2001 ), p. 108.Google Scholar
  19. 19.
    Scott W. Ambler, Agile Modeling. Effective Practices for eXtreme Programming and the Unified Process ( NewYork, NY: John Wiley & Sons, 2002 ), p. 31.Google Scholar
  20. 20.
    Kent Beck, Extreme Programming Explained: Embrace Change ( NewYork, NY: Addison-Wesley, 2000 ), p. 32.Google Scholar
  21. 21.
    Ibid., p. 32. Also see the “sheer thrill” quote in the section “The Perpetual Coding Machine (Embracing Change)” in Chapter 13 of this book.Google Scholar
  22. 22.
    Martin Fowler, op. cit., p. 63.Google Scholar
  23. 23.
    Scott Ambler, “Why Data Models Shouldn’t Drive Object Models (And Vice Versa),” http://www.agiledata.org/essays/drivingForces.htm1,2003.
  24. 24.
    Martin Fowler and Pramod Sadalage, “Evolutionary Database Design,” http://martinfowler.com/articles/evodb.html.Google Scholar

Copyright information

© Matt Stephens and Doug Rosenberg 2003

Authors and Affiliations

  • Matt Stephens
  • Doug Rosenberg

There are no affiliations available

Personalised recommendations