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.
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 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.
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.
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.
