Why Extreme Programming?
------------------------
Extreme Programming takes OOP principals and applies them to the complete
programming process. These methodlogies, adopted by many cutting edge software
developers, seeks to streamline the software developing process. Note the
following methodolgy was adapated from the rules and systems developed by
http://www.extremeprogramming.org.
Extreme Programming
Methodologies
---------------------------------
I) Planning
A) Obtain "user stories"
- Specific use case examples developed by potential
users
- Details desired needs to HumanML_Write cosumers and
developers
B) Release Plan Meeting
- Discuss collected user stories and develop release plan for whole
project
C) Iterative Development
- Divide and conquer method
- Create development schedule
into about a dozen iterations of 1 to 3 weeks in length.
II) Designing
A) Focus on code simplicity
B) Focus on consistent system metaphor
- Team must name classes and methods consistently
C) Class, Responsibilities, and Collaboration Cards (CRC)
- Allows for greater team collabortation and input
- Moves
focus away from procedure to an object focus
D) Periodic "Spike Solutions"
- Create spike solutions to figure out answers to tough technical
or design problems.
- A spike solution is a very simple program to
explore potential solutions.
- When a technical difficulty threatens to hold up the system's
development put a pair of developers on the problem for a week or two and
reduce the potential risk.
E) Refactoring
- When we remove redundancy, eliminate unused functionality, and
rejuvenate obsolete designs we are refactoring.
III) Coding
A) Focus on potential audience of users
- All coding and design focus should stem from user stories,
requirments, and needs of potential users
B) All coding must be done according to agreed standards
- HumanML_Write shall be written in Java for maximum cross platform
compatabilty
C) Code the Unit Test First
- Create a test for program's success prior to intial
coding
- Allows for outcome produced coding pratices
D) Pair Programming
- Each task should be done by two programmers
simultaneously
- Not sure how this can be done under this particular
context
- Perhaps each coding section should be passed around between
partners
E) Code Intergration
- Continuous integration often avoids diverging or fragmented
development efforts
F) Collective Code Ownership
- No one person controls or owns any single part of the
project
- Collective Code Ownership encourages everyone to contribute
new ideas to all segments of the project
- Any developer can change
any line of code to add functionality, fix bugs, or refactor
-No one
person becomes a bottle neck for changes.
IV)Testing
A) Unit Tests
- Extensive testing to every
class in the system prior to release
- Code without proper tests may
not be released
B) Dealing with bugs
- Must create an "acceptance test" first
- This helps
programmers to concisely define the problem
C) Acceptance Tests
- Acceptance tests are black box system tests
- Each
acceptance test represents some expected result from the system
-
Whan all acceptance tests are passed then, and only then, can the code be
published.