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.
On this page:Page
|Table of Contents|
Reviews are scheduled for every thursday. In the weekly KIELER meeting one author and two reviewers are chosen.
Design reviews are scheduled during our various project meetings. For each review, one author and at least two reviewers (though not more than three) are selected. Design reviews take place during special design review meetings. The author's job is to prepare for the meeting by doing the following:
- Choose the classes that are to be reviewed.
- Prepare a meeting page in our Wiki.
- Fill the meeting page with all information necessary for the reviewers to prepare for the code review. That may include class or sequence diagrams. You may also want to take this opportunity to add documentation about the reviewed bits and pieces to the Wiki and link to that documentation from the meeting page.
Now the reviewers look at your meeting page and through the code that is to be reviewed. During the meeting, you will discuss the comments of the reviewers and take notes of all change decisions in the meeting notes. After the review, the author goes through all decisions and gets the changes done, noting so in the notes. The author also adds a tag to the reviewed classes to mark them as design reviewed (see below).
Code reviews are scheduled during our various project meetings. For each review, one author and at least two reviewers (though not more than three) are selected. 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 turn of 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
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
If you have never reviewed source code before, you might wonder what to write into the review. Here's a few things you might look out for:
Basically, look out for anything that strikes you as odd or problematic.
After the Review
After the review it is up to the author to finish any tasks that have been risenrespond to all comments the reviewers gave.
- 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)
When classes are ready for a design review, they should be marked with the following tag:
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. The comment should contain the date of the design review (yyyy-mm-dd) and the login names of the attendees.
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:
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 comment should contain the date of the code review (yyyy-mm-dd), the login names of the attendees, and the ID of the code review in Crucible (such as
Review Overview Page
The complete syntax of the available tags is as follows: