February 01, 2002
URL:http://www.drdobbs.com/my-favorite-extreme-programming-ide/184414813
I used to be a die-hard fan of the stand-alone source-code editor. You know the type: I fired up my code editor on every project for a wide variety of languages, and could often be heard saying things like "IDEs are for wimps," "My editor handles any language," and "Who needs a debugger? The code I write isn't very buggy." Today, I'm a changed man. My tool of choice for solo or team-based Java programming is IBM's Visual Age for Java Enterprise Edition 3.5 (VAJ). Over the past few years I've found that VAJ is an excellent tool for doing Extreme Programming (XP).
Before I explain further why VAJ is so good for XP, I'd like to get a few things out of the way. First, I have no connection with IBM, so this article isn't a disguised marketing message. Second, this isn't a comprehensive look at all that VAJ providesit offers a lot, but I'm just interested in showing you how it helps us do XP efficiently. Finally, you may have tried VAJ and disliked it. That happened to me too, in 1998. But the folks I was programming with back then didn't really know how to use the tool effectively, so my perspective on VAJ was warped. When I later pair-programmed with people who really knew how to use VAJ, I was surprised to discover how great it was. So perhaps my experience will help you approach this tool with an open mind.
Living on the Collective
VAJ is particularly great at version control, which is vital for Extreme Programmers,
since we collectively own our code (anyone can change anything at any time),
continuously integrate code (many times a day), and mercilessly refactor it.
With such changes happening so frequently, it helps to be able to quickly, easily
and safely view, compare or revert to different versions of a method, class,
package or project. While you can do that with nearly all of the popular version-control
packages, some of which integrate into editors or IDEs, using those tools is
awkward compared to what you get with VAJ.
Time-Stamped Methods [click for larger image] As I'm working on the method, wrap(...) , I
want to see what an older version looks like. I simply right-click on the
method name, choose "Compare With," select "Another Edition,"
and bang, VAJ gives me a time-stamped list of all previous versions of the
method (pictured above). To see the code for each edition, I simply click
on a time stamp. |
VAJ makes life easy by providing powerful, built-in version control tools that can be accessed via a few mouse clicks. I recall being amazed the first time I discovered that VAJ was storing snapshots of every version of a method I had saved (see Time-Stamped Methods). This feature allowed me to comfortably make changes to a method, knowing that I could easily and quickly revert to an earlier edition with a minimum of effort. Merging code is also easy in VAJ, since it provides convenient comparison views of different versions of a package. Such views simplify the always-difficult task of figuring out how your code changed from its original version to its latest version.
But the real secret to using VAJ's version control on an XP project is to use a simple version-control strategy, which begins with a single user sign-on: We don't care who wrote what code, so everyone logs in as "XPUser." We don't lock code, for doing so would violate XP's collective code ownership practice. And when we version code, we rely on VAJ's clever and simple numbering scheme, which suggests version numbers that reflect what code changes the entire team has already made. We add one simple twist to thiswe version only at the project and package level. This means that if we want to modify code within a project (which is essentially a collection of Java packages) or a package, we mark the project or package as an "open edition" and make our changes. Thus, we create a new version by letting VAJ suggest a version number for us and ignoring the version numbers VAJ automatically assigns to the code within our packages (See the "Versioning in VAJ, Extreme Programming Style" sidebar).
This simple way of using VAJ's version control has worked beautifully both in solo practice and in teams from eight to 25 people. And because it is so simple, it enables us to implement XP's continuous integration practice with great efficiency.
No More Big Builds
VAJ's incremental compiler also improves our development speed. In most IDEs,
such as JBuilder or VisualCafé, or source-code editors (like SlickEdit,
IntelliJ or emacs), you edit a file, save it, and then invoke some command to
compile the code or rebuild everything that needs to be compiled. In VAJ, every
time you save a method, the compiler kicks in automatically and does the job
for you, so there's no "build" menu item in VAJ, no "rebuild"
option; not even a "compile" option. Incremental compilation just
happens every time you save a method, variable declaration, class declaration,
import statement and so on.
VAJ Suggestions [click for larger image] In this method I've used Java's ArrayList class,
but I haven't provided an import statement for it. When I save the method,
VAJ's incremental compiler shows me the error message(s). If I click on
an error message, VAJ attempts to offer a suggested correction. In this
case, one of the suggestions is to add the import statement, java.util.* .
If I click on that suggestion and choose "correct," VAJ automatically
applies the correction. |
This feature creates time-saving magic. For example, say I save something that the incremental compiler sees has a problem. VAJ warns me, offering the option of fixing the problem now or adding it to the Problems page and fixing it later. If I choose to deal with the problem(s) immediately, VAJ suggests possible solutions (see graphic). If I choose to ignore the problem for the moment, VAJ saves the code, but places an X icon next to the name of the field, method and/or class containing the problem. These Xes make it easy for veteran and novice programmers alike to immediately see how a change to one part of the code can affect other parts. Compare that to what happens if a programmer makes many changes to some code, then saves, and then compiles, only to find a mountain of errorssounds familiar? Incremental compilation embodies XP's value of feedback: It gives programmers feedback as fast as possible.
Efficient Debugging
Incremental compilation also makes debugging sessions more efficient. When I
was still a fairly new VAJ user, I was pair-programming with a woman at Evant,
an application service provider in San Francisco. We were running some JUnit
tests, one of which had just failed. A quick look at the code did not reveal
the solution, so we decided to use the debugger. We set a breakpoint in our
test code, told JUnit to rerun the test, and in a few seconds we were positioned
on our breakpoint, ready to debug. We stepped into a method, then another method,
and a few steps later we were in the method that contained the bug. We were
on line 4, and I spotted the problem on line 2. That's when my partner simply
fixed line 2, saved (think "incremental compiler doing its magic"),
and then chose a wonderful little option in the debugger that allowed us to
re-enter the method as if we had not entered it already! Our test code ran successfully,
and I was amazed. We had just changed a line of code while debugging, rerun
only the method we had changed (not the whole program) and seen JUnit report
that our test had run successfully. It's also worth noting that VAJ has excellent
support for debugging servlet-based code, since it can create two separate JVMs:
one for the client and one for your servlet.
Automated Refactorings
Refactoringimproving the design of code without changing its behavioris
something Extreme Programmers do all the time. But refactoring manually can
slow you down. So VAJ has an excellent refactoring plug-in tool called jFactor
(by Instantiations), which seamlessly integrates with VAJ as well as with Borland's
JBuilder. When you click on a class or method or highlight some chunk of code,
jFactor will provide you with a list of possible refactorings. Choose one, and
the tool will ask you for some informationand then safely perform the
refactoring for you. The only downside to this tool, at the moment, is that
it doesn't support undo, and it isn't cheap. Nevertheless, I'm addicted to using
it since it speeds up my refactoring work.
VAJ has excellent searching capabilities, including the ability to easily find all callers of a method or find the methods and fields referenced by a method. It has basic capabilities to move, copy or rename chunks of code. It has capabilities to set coding format standards. And, like so many IDEs today, it has a code-assist feature designed to help you remember which method to call, and what parameters that method expects.
The Competition
We've explored what makes VAJ good for XP and in a moment, we'll look at why
VAJ is not so good for XP, but let's now ask "Why isn't it better to do
XP using a smart code editor, JUnit and some external version control tool,
like CVS?" For example, IDEA's IntelliJ (see "The
J Factor," Hello, World! Dec. 2001) is a very good tool. It makes Java
coding faster and easier by automating many common coding tasks, provides built-in,
automated refactoring support, integrates with version control packages like
CVS, and comes with a powerful debugger. That's a strong package! But I've used
stand-alone source editors and CVS on XP projects and I've found that they don't
work as well as VAJ when a team is collectively owning their code, continuously
integrating it and mercilessly refactoring it. VAJ's version control is simply
a joy to use on an XP projectits incremental compiler speeds development
by avoiding lengthy builds, saving precious time when you're frequently refactoring
and integrating; and VAJ's plug-in, jFactor, includes support for an ever-growing,
powerful set of context-sensitive, automated refactorings. And, though test-first
programming dramatically reduces the need for debugging, when we have to do
it, VAJ's debugger lets us change code while debugging, saving loads of time.
Nevertheless, IntelliJ is a close contender with VAJ, and I suspect that it
and other commercial IDEs may soon rival VAJ as the tool of choice for XP.
Mucho Memory, Slow Execution
VAJ helps Extreme Programmers develop software efficiently, but what are its
downsides? Well, the enterprise version, which gives you team-level version
control, is pricey, but don't forget the cost of the time you waste by not using
a powerful tool like VAJthe same argument you'd make for a tool like jFactor).
VAJ also hogs memory, which can increase your hardware budget. VAJ isn't a speed
demon at running Java. So if you need super-fast execution during development,
it's time to make some choices. On one Extreme Programming project, we found
that our tests were taking nearly 40 minutes to run. Granted, we had a lot of
test code, but this slow execution time was unacceptable, since it was causing
a traffic jam at our integration machine. We got around this problem by optimizing
our test code and by writing some VAJ code to export any changed code from our
VAJ projects to the file system, where we could then run the tests under a fast
JRE. That substantially improved performance.
VAJ also locks you into a certain level of the JDK, so if you need a new feature in the latest JDK release, you're out of luck. In VAJ's early days when, for instance, it didn't even support the JDK 1.1 inner classes, this was a problem, but the projects I've worked on over the past few years haven't needed features beyond those provided in JDK 1.2 (which VAJ 3.5 supports).VAJ has another bad habit: It alphabetizes your code. So if you want all of your constructors and field declarations to be at the top of your class, make sure they all start with the letter A. This is quite irritating, particularly when you export code from VAJ to share it with others.
The Eclipse Java IDE [click for larger image] An X icon appears just after the setUp()
method because it is missing a semicolon. This icon is also shown in the
tree view to the leftwith the X being propagated all the way
from the method to its class and its package. A tool tip for the runTest()
method is showing. |
Eclipse
Fortunately, IBM has addressed nearly all of the above shortcomings with an
exciting new project and product called Eclipse ( www.eclipse.org
). Eclipse has been programmed purely in Java by Amsterdam and Phoenix, Arizona-based
Object Technology International, an IBM company. Eclipse is a free, sophisticated
open-source platform on which the public may create its own tools, IDEs or Eclipse
plug-ins. The Eclipse Java IDE (see screen shot) is itself a set of plug-ins
to the base Eclipse platform, which was designed to be language-independent.
This IDE no longer locks you into any particular JDK and it includes VAJ's sophisticated
version control features, but it uses popular packages like CVS or ClearCase
as the version-control engine, instead of IBM's proprietary code. The OTI team
has already written an excellent JUnit plug-in for Eclipse, and common refactorings,
like Extract Method, are included, are undoable, and, because of the open-source
nature of this project, should grow in number. Code-assist support is improved
over the current VAJ, and general editing is good, though not at the level of
a tool like IntelliJ's IDEA, as of this writing. Speed of the tool seems comparable
to most contenders. Overall, I'm very excited about Eclipse as an Extreme Programming
development tool and a successor to Visual Age. Finally, the free price tag
couldn't be nicer.
Best Practices
Joshua Kerievsky |
Versioning in VAJ, Extreme Programming Style The Non-Branching Case
The Branching Case This scenario is essentially identical to the one above. Imagine that the package, games.industriallogic.ui, now has a released version number of 9.3. Two pairs, A and B, are working on this package at the same time. Pair B creates a version of the package before Pair A, and obtains the suggested version number, 9.4. When Pair A versions their package, they obtain the suggested version number, 9.3.0. Since Pair B has a non-branching version number, they can integrate their code as outlined in the first scenario. Pair A has a little more work to do, though VAJ's integration tools will greatly assist them. Everything is the same through step 5 above, but then the two paths diverge.
Joshua Kerievsky |
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.