In the KIELER project we are conducting regular code reviews of (possibly) all of our sources. To make things easier, we do software assisted reviews in Crucible.

Review Scheme

Reviews are scheduled for every thursday. In the weekly KIELER meeting one author and two reviewers are chosen.

The author's job is then to do as follows:

Choose about four Java classes that are to be reviewed

Create a Review Task in Jira

Create a review in Crucible

Invite the two reviewers to the review

Now it is the reviewers's turn to perform the review:

Read the source code of the class files in Crucible

Understand the source code and the class files

Write a comment if there is something that needs to be improved and mark the comment as defect

If you want to put more emphasis in your opinion, create a corresponding Jira issue for the defect directly from Crucible

Write a comment if there is anything that is not understood

Review Meeting

The week after, on Thursday, the review meeting takes place. In the Meeting the following exciting things happen

The moderator welcomes the author and the reviewers to the meeting

The moderator asks for further general remarks

The moderator reads all comments aloud

If there are any questions, reviewers or the author interrupt the moderator and start discussing

The moderator keeps the discussion brief

Finally, the moderator asks if any further remarks have arisen during the review

After the Review

After the review it is up to the author to finish any tasks that have been risen

The author goes through all comments in Crucible and leaves a note about his decision

The author may schedule a followup meeting which is only held online to review for example auxiliary classes

The author adds a tag to the reviewed classes to mark them as reviewed according to the proposed rating (see below)

Code Tags

When classes are ready for a design review, they should be marked with the following tag:

@kieler.design proposed <comment>

After the design review has been performed, the same tag can be used to mark the reviewed classes by removing the proposed modifier and adapting the comment.

All classes have initial code review rating red. The first code review lifts them to yellow, and the second one to green. The following tag marks classes that are ready for the first code review:

@kieler.rating proposed yellow <comment>

After the code review has been performed, the same tag can be used to mark the reviewed classes by removing the proposed modifier and adapting the comment. Similarly, the second code review can be marked using the green modifier.

The design and code review tags are processed automatically using a custom doclet during Bamboo builds. The result is displayed in a generated HTML page: