Review Board: Code Reviews on the Web

Today I had a happy surprise. In a discussion on a local linux related mailing list, someone pointed to Review Board as a good alternative for doing code reviews.



I looked at the webpage and it looks very, very good. I will check it out as soon as I can, and play with it a bit before trying to “sell” it in my job, but I am pretty confident it will be well received. As a plus, It has people from a recognized company behind it: VMWare. And, another plus for me: it is made in Python, using Django.

I am very interested, because I did something related in the past, using the very same development platform. Before being abducted by the company to do management tasks, I was playing with a pet project to do code browsing, reviewing and project planning, where code review was the first focus. It is called “codeflow”



I left it practically abandoned when my position in the company changed: I had no way to eat my own dogfood anymore. Before that, back in April, I managed to get a working prototype wich did fancy diffs, code highlighting and worked against our subversion repository, although it was not very polished:



We tested the prototype and it showed to be very useful, for real projects. Even
now, one or two months ago, the main engineering team (I am into research and development right now) wanted to put that prototype into production. But I was not sure it was a good idea.

I believe in “release early, release often”. But without enough time to actually release anything, it would be quite difficult to do it often.

So I am now going to push Review Board, as a working product, instead of my rough prototype. As far as I can see, the ideas for codeflow about code reviews were not any bad. I will still miss the integrated concept which I envisioned for codeflow back in April, but I will not miss the reviewing platform anymore.

And it is done on Python/Django. I am familiar and proficient with both. I am still looking forward to do something with the ideas behind codeflow (not limited to code reviewing), and Review Board looks like a great place to start.

On Code Excess

Code size is a problem of in software engineering. Some people even think it is the most important problem we have.

But it is not code size alone. You may not be working on a mammoth code base, but code size may still be a problem. Being more precise, excess of code is always a problem. Obviously, it is worse on enormous and intractable system, but it is painful everywhere.

Today I experimented this by trying to rename a bunch of methods of a class. The class was in the DAO layer of an application with at least two layers on top of it: EJBs and “business delegates”. As the rename method refactor does not work through delegation, find and replace was better suited for my particular case. It comes with the price of checking that the search pattern does not occur in other places. I was luck and the pattern was not found elsewhere, so it was cheap and far less tiresome than repeating every rename operation three or four times.

I think it is a bit ironic how some program's source seem to be made to work against the tools, almost like on purpose. Java programs tend to be massive and verbose, basically for cultural reasons, but also as a consequence of the limitation of the language. Big codebases were born and typical text editors fell short.

To fix this, wonderful IDEs have emerged. They allow us to browse the mess we create, and to create more of it. As modifying the mess came to be a major problem, refactoring tools came to the rescue and were integrated into the IDEs.

Today, I stare at the pointless layers of this system and see how they defeat many automatic refactors. Not only rename method, but also push down, pull up and maybe others. Maybe, in the future, some refactors will detect delegation and work through it.

I will not deny the usefulness of such improvement if it happens, but I am pretty sure that they are solving the wrong problem. Code excess is the problem. Pointless layers “just if some day we want do it in another way” are the problem. Violating DRY is the problem. Not realizing that YAGNI is the problem.

In the end, it seems like a people problem, backed by technology.