Level: Introductory Allison Wilson (allison1@us.ibm.com), e-business Architect, IBM
01 Apr 2001 The following article describes some best practices for using one of
today's hottest development methodologies with a leading Java IDE: Extreme Programming with VisualAge
for Java.
Today's application development environment is as fast paced as ever. Many development shops are
turning to application development methodologies, such as Extreme Programming (XP), to help them
effectively manage their development processes and quickly create code that meets user expectations
and is of high quality. Many development shops also are relying on powerful Integrated Development
Environments (IDEs), such as IBM VisualAge for Java, to help them quickly develop and assemble
complex applications. Unfortunately, it is not always obvious how best to implement an application development
methodology with a given IDE. Extreme Programming
XP is a methodology for rapid development of flexible applications. XP, which is well suited
for small development teams, takes traditional programming practices to the
extreme-hence
the name. Take a look at Extreme Programming: A gentle
introduction for a good, quick overview. The basic tenets of XP include:
- Short release cycles
- Simple designs
- Writing tests before code
- Refactoring
- Pair programming
- Collective code ownership
- Continuous integration
- Strict coding standards
Many developers who have never used XP are skeptical about its feasibility. The key concept to
embrace is that all the practices that comprise XP support each other-the weakness of one
practice is compensated by the strength of another. For instance, you may be thinking that collective
code ownership would be a disaster, leading to people stepping on each other's code right and left.
However, XP's practices of short release cycles and continuous integration ensure there is less
opportunity for conflicts. Religiously writing and running tests prevents developers from accidentally
breaking code, and strict coding standards along with pair programming ensure code quality and
consistency. Since XP practices are highly dependent on one another, it is essential that an XP project thoroughly
implements each practice. However, some of these practices (collective code ownership in particular)
present challenges when implemented with IDEs such as VisualAge. XP demands a nonstandard approach to
setting up and using an IDE.
VisualAge for Java
VisualAge for Java is an IDE for professional Java programmers. VisualAge comes in three
flavors: Entry, Professional, and Enterprise. This article focuses on the Enterprise edition, which
provides support for collaborative team development, a requirement for XP. VisualAge for Java Enterprise Edition can provide source control through a shared team repository.
The repository, which contains all editions of all program elements, allows a team to manage code and
to track changes. In a traditional development environment, project code has an associated hierarchy
of owners, with program element owners taking the responsibility to manage the continuous integration
of their elements into a team baseline. Each developer has a set of privileges related to the
developer's team role (package owner, class owner, class developer, and so on). For example, two
class developers may have privileges to create open editions of a class and modify the code. The
class owner has the authority to compare the two editions and merge them into a single version that
the owner can release into the containing package. The clearly defined roles and privileges in this
approach help ensure that team members do not step on each other's code and that they are working from
the same code baseline. However, this hierarchical model of individual privileges does not work well on XP projects where
everyone owns all the code. In the previous example, all three developers would require the privileges
to not only create an open edition of and modify the class but to also merge different versions and
release the code into the team baseline. The good news is that while VisualAge for Java was architected
for teams with distinctly implemented individual roles, it can be adapted to accommodate XP's more
communal coding practices.
Best practices when using VisualAge for Java on an XP project
There are several techniques for effectively using VisualAge for Java on an XP project. These
techniques assume that your project is zealously following the practices that comprise XP. All XP's
practices demand a high degree of collaboration and communication. As you read the following suggestions
for best practices, you learn why collaboration and communication are so critical to this methodology. Set up one userid for all developers
XP indicates that all developers should own all the code. With VisualAge for Java's clearly defined
team roles and schema for code ownership, how will you do this? Set up one userid shared by all your
developers to ensure collective code ownership in VisualAge. After installing VisualAge for Java and creating a VisualAge project, use the User Administration
window (Window --> Repository Explorer --> Admin --> Users...) to add the userid for all your
developers. All developers will log in using this common userid and the associated password. Typically,
the developers' userid is set up as Project Owner of the project that will contain your application's
code. As Project Owner, each developer will have full privileges to create, modify, merge, delete, and
release code within the project.
Note: You should maintain a separate userid designated as the Repository Administrator.
The Repository Administrator, often a LAN administrator, is responsible for setting up and maintaining
the shared-team repository. Usually, only one or two people on the project need Repository Administrator
rights. Understand VisualAge source control
To successfully manage an environment where every developer is using the same userid, be mindful
of how VisualAge manages editions and versions of program elements. As pairs of programmers work, they
take application code through the stages of the XP development process and should understand how these
stages map to VisualAge's source control mechanisms. In a typical scenario, a programming pair begins by replacing the current project edition in their workspace with the latest version available from the team repository. They create open editions of the project and any packages in which they intend to work. If an open edition of the package is not created initially, the package version may fall out of step with the project version. This can result in the next pair of developers not getting the latest package code when they replace their workspace edition of the project with the latest from the repository. Once open editions of the project and packages are created, the programming pair proceeds to create
or modify unit tests and program code. In XP, a program element becomes a release candidate when coding
is complete; however, successful execution of tests is required before the code is released. Upon
completion of successful testing, the programming pair will version and release the code they modified
into the team baseline. Keep an eye out for version branching
Occasionally, multiple pairs of programmers may be working on the same piece of code. When this
occurs, the version numbers assigned by VisualAge will begin to branch. For example,
if com.ibm.myPackage was at version 1.1 before a pair began programming, it should increment to
version 1.2 when they version it. However, if another pair were working on com.ibm.myPackage at the
same time, the version would increment to 1.1.1 for the first pair and to 1.1.2 for the second pair.
The two pairs of programmers should notice this branching, seek each other out, and figure out how to
integrate their efforts.
You may be thinking that your team will very quickly run into problems stepping on each other's code.
However, if you are a religious XPer, these duplicative efforts should be infrequent; and when they
occur, they should be swiftly recognized and handled. To help ensure this, another best practice is to
designate a person or team to coordinate integration efforts for each iteration. The role of the integration coordinator, which may rotate among project members, entails keeping
an eye on code development and helping guide the continuous integration of program elements. The
integration coordinator should have a solid understanding of VisualAge's source control mechanisms
and be aware of the iteration tasks and the developers signed up for them. Throughout the course of
each iteration, this person helps ensure that the team baseline contains the most up-to-date editions
of all program elements and that the versions of individual program elements are not branching. Use VisualAge's code format utility
In addition to managing the collective code ownership aspect of XP, take advantage of VisualAge to
help ensure strict coding standards. Strict coding standards are another critical XP practice that
helps support collaborative programming by promoting code readability as many different developers work
on the same pieces of code. VisualAge provides a code formatting utility that automatically formats
code in one consistent manner. You can change the code format defaults in VisualAge's Options window
(Window --> Options), but ensure that all team members are using the same settings. Programming pairs
can use the utility to format their code by right clicking in VisualAge's source pane and selecting
Format Code.
Conclusion
As we have seen, there are some tricks to getting the most out of VisualAge for Java on an Extreme
Programming project. Best practices include setting up one userid for all developers, understanding
and being mindful of VisualAge source control mechanisms, and taking advantage of the code format
utility provided in VisualAge. With a thoughtful approach and these simple steps, VisualAge can augment
the innovative and highly effective practices of XP.
Resources
About the author  | | |
Allison Pearce Wilson is an e-business Architect in the IBM Developer Relations organization in
Austin, Texas. As a part of IBM Developer Relations, Allison provides technical consulting on the
IBM Framework for e-business to IBM Business Partners worldwide. In the great tradition of liberal
arts degree programs, this work is almost completely unrelated to her BA in education from Smith
College. You can contact her at allison1@us.ibm.com.
|
Rate this page
| 
