Home   Info   DevZone   Wiki   UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
[ ExtremeProgramming ] [ not logged in ] [ Web: Imported ] goto:  options [ get info on or edit ] [ login or new user ] [ list of topics, hubs & nodes, or recent changes ]

eXtreme Programming Summary (for JOS)

(taken from Ron Jefferies Extreme Programming papers - see reference below).

When in doubt about these practises, get a few people together and decide what to do.

Simplicity *+* Communication *+* Testing *=* Aggressiveness

Simplicity

• "Do the simplest thing that could possibly work"
• NEVER work on something "we’re gonna need"

• Code so as to express intention, not algorithm.
• Method names say what they accomplish, not how they accomplish it.
• Use CRC cards (--ClassResponsibiltiesAndCollaboration)

• Every class must have a corresponding unit test class.
• Each public method should have at least one unit test method.
• All the unit tests must run at 100% to release code.
• Functional Tests test system from end to end.

• We can change any part of the system to be better because we know we have a solid system of tests.
• We know we won’t break the system, which gives us the confidence to move forward rapidly.

• When we feel like breaking the formatting rules to make a method look better, we get better code by reformatting, in almost all cases. Give it a try.

• If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. (ie don't nest your functions too deep - StefanBorg)
• Methods should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well.
• The maximum length of a function is inversely proportional to the complexity and indentation level of that function. So, if you have a conceptually simple function that is just one long (but simple) switch-statement, where you have to do lots of small things for a lot of different cases, it's ok to have a longer function.
• LOCAL variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, if there is no chance of it being mis-understood. Similarly, "tmp" can be just about any type of variable that is used to hold a temporary value.
• Number of local variables shouldn't exceed 5-10 per method, or you're doing something wrong. Re-think the function, and split it into smaller pieces.
• Your comments tell WHAT and possibly WHY your code does what it does, not HOW.

We call the combination of frequent release with tests at 100%: continuous integration, relentless testing . The result is rapid progress and a system that always works better than it did the day before.

(see --ClassResponsibiltiesAndCollaboration)

(The following figures don't apply with JOS BUT should be proportional --StefanBorg)

• Teams consist of two people
• Bugs/features were broken down into engineering tasks.
• If task appears to require more than one engineering week, it must be broken down further.
• Task iterations are 3 weeks
• 1 task per team per iteration

• If the estimates for a task are so wrong that it doesn’t complete within an iteration, it is likely that something isn’t understood about the task.
• Quite possibly the team is trying to solve a problem that is too hard because of something wrong elsewhere in the system.
• If a task isn’t going well, it’s probably on the wrong track and needs to be reset. Even if the code finally works, it will continue to be a problem.
• When a solution isn’t fitting into the system, either the system is wrong or the solution is wrong.

• There is some written documentation for the software, more commonly interpreting requirements than documenting design.
• Sometimes we document an approach to some particularly difficult area.
• We "never" document code. (We rarely even comment it.)

• We do not believe that it would help us go faster;
• We do not believe that it would make the system more reliable;
• We do not believe that it would make the system more maintainable.

• It might help other groups benefit from our process;
• It would make interesting reading to our customers;
• It would serve as the basis for useful papers in journals and conferences.

• Version frequently. Always version at end of day, to make it easier to bring the code up tomorrow.
• Our development teams typically release their software at least once per day. Yes, release. Yes, at least once per day.

• The test cases were defined by the users, and developed by a separate team whose job was to create tests.
• Functional tests have their own special GUI, which displays each step of the test, its execution time, and whether or not it succeeded. There is a score displayed.
• Functional tests did not have to score 100% during the project: adding features makes their scores go up. They do have to score 100% before release, and any substantial change in the tests is always worthy of note.

Scope, Quality, Resources, Time

There are four inter-related aspects to a software project:

• Scope - what is to be done; the features to be implemented;
• Quality - the requirements for correctness and other "good" things;
• Resources - the investment of personnel, equipment, and so on;
• Time - the duration of the project.

• Adding Scope (features) makes Time (duration) increase. Do more, take longer.
• Increasing Quality requirements makes Time increase. Do better, take longer.
• Increasing available Resources can sometimes make Time decrease. Rarely.

(under construction)

I would like to thank Ron Jefferies for the insight found at - http://www.armaties.com/Practices/Practices.html

Kent Beck's Testing Frameworks found at - http://www.armaties.com/testfram.htm

Linux kernel Coding Style at - http://recycle.cebaf.gov/~doolitt/Linux-coding.html

Content of these pages are owned and copyrighted by the poster.
Hosted by: