Extreme Programming Jan 14 2019 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 2 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 3 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 For example it is well known that software should be tested frequently during development 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 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 4 XP values Communication Simplicity From the system Unit tests From the customer Acceptance tests From the team Estimate the time to implement new requirements Courage Follow the KISS principle Keep It Simple Stupid Feedback Use simple designs and common metaphors talk continuously with your programmers and customers Code for today not tomorrow Refactor as appropriate Be willing to throw code away Respect Trust your team members not to submit nonworking code 5 XP practices Fine scale feedback Pair Programming Planning Game Test Driven Development Whole Team Continuous process Continuous Integration Design Improvement Small Releases Shared understanding Coding Standards Collective Code Ownership Simple Design System Metaphor Programmer welfare Sustainable Pace Source http en wikipedia org wiki Extreme programming 6 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 http www pairprogramming com 7 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 possible 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 8 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 testable Writing tests first encourages you to write simpler single purpose methods 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 environment To do TDD it must be easy to create and run tests JUnit is a framework that makes this much easier to do 9 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 10 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 learn 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 11 Simple design Do the simplest thing that can possibly work Program for the features you need today not the ones you think you will want tomorrow Complexity to achieve program efficiency is almost always a very bad investment Complexity to support future features is seldom a good idea 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 12 XP in this course Do pair programming in labs and work as
View Full Document
Unlocking...