The Thirteenth Step

Well, as the title clearly states this blog is "on everything", so today I want to talk a little about software development in general. I have been interested in software development and related topics for quite a while now, and if I would have to name one person who had the most influence on my views and opinions on the subject it would without a shadow of a doubt be Joel Spolsky.

Back in 2000, Joel has introduced a Test to measure how good a software company is using twelve simple criteria. The Test is very useful, in fact, it is successfully used to rank software companies that appear on Joel's job listing site, and provide a great reference for job hunting developers.

One thing, however, bothers me a little, and it's an issue of a "code review".

A "code review" is, naturally, a process in which a portion of written code is read and examined visually by programmer's peers or superiors short time after it is written and usually before it is committed to a next build or release. This is by no means a definition, "code review" has many uses, but it's the phrasing I would use for the purpose of creation of another step in Joel's test.

"Step 13: Do you have a regular code review? "

Maybe it is so trivial that it is implied and maybe not, I think it is worth mentioning explicitly and I will try to explain why.

Although most would agree that "code review" is a useful and effective practice for continuous improvement of code quality, not everyone is actually doing it, to any extent. The reasons, or to be more precise - excuses, ranges from "I am the best programmer they have there, no one can review MY code" to "We would be glad to, but it takes too much time to review all the code we write here". There are also those who say: "We are so agile, we review our code as we write it". Well, if all your code is written in pairs, then I think you are covered.

It does not take a programming genius to review somebody else's (even another genius's) code. First, if the code is that good it is usually readable and well commented, isn't it. And if it is not, well, here is where the questions will start. In any case, a fresh pair of eyes and a new perspective will already allow to discover wide variety of problems.

The issue of the personal abilities of the reviewer is so unimportant that I once thought of creating a tool called "semantic debugger". It would go over a code, compiler style, analyze it a little and ask you random questions like: "What is this variable for?", "When do you enter this function?", "Why is this exception unhandled?" and so on. I think the very fact that a programmer would have to think about answering those questions would by itself uncover a bug or two.

To conclude, the "code review" helps to find bugs, improves coding style consistency, allows less experienced programmers to learn from the more experienced ones and much more. A code review is definitely an important procedure one would want in a good software team, and possibly important enough to make Joel's list.

P.S. To the more theoretically minded, here is a link to an interesting work(.PDF) on how to estimate the number of problems that iterative code review allows to discover.

Why would you use the Package Explorer to delete a function from your class?

This is a good question, however, since it is allowed, I might as well do it if I please. One might, if so inclined, expand a class in the Package Explorer and the delete a specific function or member or whatever, no problem at all.

There is however a little something one should be aware of. In case this operation is performed on a class that is not currently open in an editor, there will be no going back - no undo will be available!

I have discovered this little glitch while trying to work with the new Common Navigator framework that was added to the 3.2. After reading the excellent tutorials on the subject, I have tried to create a view very similar to the Package Explorer, but for my own file types. In order to show the contents of my file, the view should be aware of my model. In case the file is also being edited in the editor, the Common Navigator view should be updated to reflect the current state of the model and correctly display the model in the tree. In the tutorial example this is done via the file system - each time the file is saved in the editor the navigator view is notified and updated. This is OK, for the example, but it is very inconvenient when working with a real model. Also, this is not a way Package Explorer behaves, a function appears there as soon as it is written even before the file is actually saved.

A friend I have been working with has suggested to put a model in a singleton container, so that it would be accessible from both a view and an editor, and implement some kind of notification mechanism to track the changes. That eliminated the need to reload the file from the Navigator view each time a change was made. Everything looked really good.

Until we started to implement the actions we wanted to perform on our model elements from the Navigator View. There we discovered that it was impossible to undo the operation that was performed on the model when the editor was closed, since that's where our command stack has resided. The only solution we saw was to move the command stack from the editor to the same singleton and thus allow to undo the performed operations from both the editor and the Navigator view.

During our attempts to determine whether this was a wise decision, we asked ourselves how did this work in the Package Explorer? Well, the problem was there too. The undo for operations on the file contents did not work, unless an editor was open, and even then it only worked from the editor and not from the view itself.

Unfortunately, we did not yet have time to go deeper into the code of the Package Explorer to understandit's inner workings. We also did not find a bug on this in the list. So meanwhile, the question remains: where to hold the model and the command stack so that both actions and their undo are available from both the Editor and the Navigator.

If, by any chance you know someone who knows the answer to these questions, please use the comments. That's what they are there for, you know :)

The Update Manager and the RCP

Two days ago I needed to create a small demo of updating an RCP application using the Update Manager as a part of the presentation I was doing on Eclipse technology. The point was to show how easy it is to update an existing application by downloading a new feature from the update site.

Since the point of the demo was the update process, I chose a simple plugin example called the "Intro". For a "new feature" that will be added, I wrote a small plugin that contributes a single menu item that would appear after the update is performed. When clicked, it displays a message box that declares that the demo has succeeded. Nothing fancy, but it illustrates the point.

All went well for a while. I used a nice tutorial to create an update site, at this point as a local directory, and published there my new feature. I also manually contributed a "Software Updates" submenu (the "Help" menu already existed in the example) and delegated the operation to the UpdateManager class as demonstrated in this article (.pdf).

And then the problem began. I would not install my feature. Whenever I checked my feature on the update site, and error status would float up declaring that "Resulting configuration does not contain the platform." Mmm, that's strange. Last time I checked the platform was alright...

Not having a clue what that meant, I tried to Google my way out of it, but it did not work out very well. A first search discovered that this specific error is either very rare, or extremely unpopular. In any case I did not find a quick fix, nor after hours of playing with configuration, adding and removing plugins from features and dependencies. It just would not install my feature.

I will make the long story short. I really should have read my tutorials thoroughly. In the RCP tutorial is clearly says that "If your product needs automatic update, then eventually you should convert it to use features." And I didn't even look in this tutorial since I thought I know what I'm doing.

Well, when I converted my RCP to use features instead of plugins the update finally succeeded. As an extra "bonus", since I included platform and RCP features, I have received the "Search" and "Run" menus, as well as another "Software Updates" submenu. Now I had two update menus when I only needed one and two additional menus I did not need at all! I was able to get rid of the search menu by removing the search plugin and I also removed my "update" menu contribution. I have decided to leave the "Run" menu and not waste time on removing it programmatically. I hope it will be easier in 3.3 :)