Extreme Programming

Document Sample
Extreme Programming Powered By Docstoc
					Extreme Programming

        Software engineering methodologies
   A methodology is a formalized process or set of practices for
    creating software
   An early methodology was the waterfall model, so named
    because each stage flowed into the next, with no backing up to a
    previous stage
       The stages were: Requirements  Design  Implementation 
        Verification  Maintenance
       The waterfall model has never been regarded as a “good” model
   Methodologies are subject to fads, and are frequently imposed on
    programmers by management
       Some methodologies are bad—even ridiculously bad
       This doesn’t mean all methodologies are bad
       However, a single methodology doesn’t work for all cases

        Agile programming methodologies
   There are (at least) two serious problems with the
    waterfall model:
       It assumes that there will be no unforeseen difficulties in the
        software development
       It assumes that the customers know (and can specify) what
        they want, in extreme detail
   Agile programming methodologies (of which there are
    several) assume:
       Customers can best discover what software meets their needs
        via frequent iterations
            Hence, communication between customers and developers is vital
       Requirements will need to be revised, probably multiple
        times, during software development
          Extreme programming
   In this course we will draw on a number of ideas from one particular agile
    methodology, Extreme Programming (XP)
   The basic idea of extreme programming is to take to an extreme each of
    several known good practices
        “The first time I was asked to lead a team, I asked them to do a little bit of the
         things I thought were sensible, like testing and reviews. The second time there was
         a lot more on the line. I thought, "Damn the torpedoes, at least this will make a
         good article," [and] asked the team to crank up all the knobs to 10 on the things I
         thought were essential and leave out everything else.” — Kent Beck
   For example, it is well known that software should be tested frequently during
        Extreme programming advocates testing code literally every few minutes, after
         every minor change
   Extreme programming works best for relatively small projects with a small
    number of good programmers

          XP values
   Communication
        Use simple designs and common metaphors, talk continuously with your
         programmers and customers
   Simplicity
        Follow the KISS principle (“Keep It Simple, Stupid!”)
   Feedback
        From the system: Unit tests
        From the customer: Acceptance tests
        From the team: Estimate the time to implement new requirements
   Courage
        Code for today, not tomorrow
        Refactor as appropriate
        Be willing to throw code away
   Respect
        Trust your team members not to submit nonworking code

        XP practices
   The XP practices we will emphasize are:
       Pair Programming
            Teams of two people
       Test Driven Development
            Writing lots of tests, and writing them early
       Continuous Integration
            Putting code together as you write it, not at the last minute
       Coding Standards
            Learn and follow well-established conventions
       Collective Code Ownership
            You are responsible for your partner’s code
       Simple Design
            Eschew obfuscation


        Pair programming is...
   TWO programmers working side-by-side, collaborating on the same design,
    algorithm, code or test. One programmer, the driver, has control of the
    keyboard/mouse and actively implements the program. The other programmer,
    the observer, continuously observes the work of the driver to identify tactical
    (syntactic, spelling, etc.) defects and also thinks strategically about the
    direction of the work. On demand, the two programmers can brainstorm any
    challenging problem. Because the two programmers periodically switch roles,
    they work together as equals to develop software.

                --Laurie Williams
                  North Carolina State University Computer Science
   Source:

        Pair programming in this course
   One purpose of the Friday lab sections is to get you started pair
    programming on each project
       After lab, you should work together with your partner as closely as
       I know this may not be easy for some of you
       At least trade email addresses, and work together that way
       Instant messaging is often better
       If you have programming problems, go first to your partner for help
   Reading assignment: All I Really Need To Know About Pair
    Programming I Learned In Kindergarten, by Laurie Williams
    and Robert Kessler (PDF)
       The URL is too long to post here, but it’s on the class web page (or you
        can just Google for it)

        Test-Driven Development (TDD)
   TDD is a technique in which you write the tests before you
    write the code you want to test
   This seems backward, but it really does work better:
       When tests are written first, you have a clearer idea what to do when you
        write the methods
       Because the tests are written first, the code is necessarily written to be
       Writing tests first encourages you to write simpler, single-purpose
       Because the methods will be called from more than one environment (the
        “real” one, plus your test class), they tend to be more independent of the
   To do TDD, it must be easy to create and run tests
       JUnit is a framework that makes this much easier to do

        Continuous integration
   Unit testing is testing a single, more-or-less independent
    part of a program in isolation
   Integration testing is testing the complete program with
    all its parts, to make certain they all work together
   Continuous integration is performing integration tests
    frequently (usually daily)
       Continuous integration is more important on larger projects
       For class projects, last-minute integration is still a bad idea

        Coding standards
   Coding standards make it simpler for your teammates
    (or yourself, weeks later) to read your code
   Java has some very well defined conventions you should
       Some conventions are strictly mechanical, such as formatting
        (spacing and indentation)
            Eclipse can, upon request, correct your formatting for you
       Some conventions require human intelligence
            Use meaningful names, with the correct part of speech
            Use adequate comments, written for the correct audience
            Prefer clearly written code to “clever” code

        Simple design
   “Do the simplest thing that can possibly work”
       Complexity to achieve program efficiency is almost always a very bad
       Complexity to support future features is seldom a good idea
   Program for the features you need today, not the ones you think
    you will want tomorrow
       With good unit tests, you can easily refactor (“revise”) your code to do
        additional tests
       YAGNI -- “You ain’t gonna need it”
   Follow the DRY principle: “Don’t repeat yourself”
       Don’t have multiple copies of identical (or very similar) code
       Don’t have redundant copies of information

        XP in this course
   Do pair programming in labs, and work as closely as possible
    with your partner outside labs
   Use TDD (test-driven development) as much as possible
       Write tests for your own code, not for your partner’s code
            We have learned the hard way that it doesn’t work for one person to write
             code and the other person to write tests for that code
       However, this really has to wait until you learn about methods and about
   Stay in touch with your partner, and integrate your code as
    frequently as feasible
   Follow the defined coding standards, including those for
   Keep your code as simple as possible
   You and your partner should turn in one copy of your program,
    with both names on it

          What I expect of you
   Work as closely as you can with your partner
        I realize this isn’t always easy
   Don’t just “contribute” your share of the code—also review your partner’s
    code, checking for problems
        It’s okay to criticize your partner’s code; it’s not okay to criticize your partner
        Don’t take suggestions/criticisms/comments personally—any code can be
   You can use all the Java you know, if your partner also understands it
        If I haven’t covered something in class (or even if I have, but your partner
         doesn’t know it), it’s your job to explain it to your partner
        If you don’t understand something in your partner’s code, ask them to explain it
         to you
   Don’t:
        Depend on your partner to do it all
        Take off and do it all yourself

 The End

“All methodologies are based on fear.”
                                         --Kent Beck

“If we asked the customers what they wanted,
 it would be devastating for the project.”
     --Team lead on a project that shall remain nameless

“Probably the earliest flyswatters were nothing
 more than some sort of striking surface attached
 to the end of a long stick.”
                                  -- Jack Handy


Shared By: