Improving Code Quality In Medical Software Through Code ... · The way how things are done has...

Improving Code Quality In Medical SoftwareThrough Code Reviews

Janne Ronkko ([email protected])

Vincit Oy

April 9, 2013

Contents

1 About Code Reviews

2 Code Reviewing In One Project

3 Summary

Outline



3 Summary

Goals In Code Reviews

Preventing bugs from ending up in product

Keeping main branch working

Quality assurance

Design verification

Knowledge sharing

There is always at least two developers who know the changeA way to see how others have solved problems

Are Code Reviews Useful?

The earlier you find issue the cheaper it is to fix the issue

Can improve your discipline

Forces the developer to reason his/her solution

There is no single developer knowing certain implementation

Are Code Reviews Useful?

”I believe that peer code reviews are the single biggest thing youcan do to improve your code”Jeff Atwood of Coding Horror athttp://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html

”Individual inspections typically catch about 60 percent of defects,which is higher than other techniques except prototyping andhigh-volume beta testing.”Steve McConnell, Code Complete 2nd Edition, page 485

http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html

Types Of Code Review

Formal code review

Peer review

Pair programming

The Traditional Code Review

A lot of code is reviewed in single session

Many participants

Preparations beforehand

Formal

The Traditional Code ReviewProblems

Iteration takes time

A lot of code

Leads discussion easily to minor issues

Peer Reviews

Usually immediately after task has been implemented

In most cases all the changes are reviewed as single entity

Part of the normal work flow

Pair Programming

Continuous review during development

Outline



About The Project

Workflow

Reviewing - The Way We Do It

Tools

3 Summary

About The Project

Overview

All changes have to be reviewed by our client before approval

Code is delivered to our client’s VCS

Changes are delivered biweekly

About The Developed Software

C++

Almost 2 million lines of code

Tens of subsystems

The development of current version started around 2000

Tens of developers, mainly located in Finland

Builds for Windows and Linux

The Vincit Team

Initially two developers

The team grew up to about 15 developers during the project

Most of the Vincit developers had no prior knowledge aboutthe software

Challenges For Developers

Large code base

Hard to remember / find utility classesFinding implementation of certain feature is not trivial

The way how things are done has evolved

Coding style has evolved

Strict rules about which C++ features are allowed

Workflow

The Initial Workflow

No peer review at Vincit

Long delay between implementation and comments

Multiple changes were reviewed as single change

Single comment list for all reviewed changes

Reviewing was split on a subsystem basis

The Initial WorkflowResults From Reviews

Mainly comments about coding style

A lot of questions why something was changed

A lot of requests to fix issues not related to the real change infiles

Changes In Project

Vincit team had grown from two (2) developers to five (5)

Changes done within one delivery cycle had grown

Time getting comments from review had grown

Something had to be done to improve the situation

The Revised Workflow

In peer review

the developer explained the change to another developer

the change was discussed

usually it was just agreed that after some changes the taskwould be ready

The Revised WorkflowResults From Reviews

Many issues were corrected before handing the code to theclient

Many enhancement ideas were discovered

Because the developer explained the code to reviewer not allthe issues that should have been fixed were fixed

But the main problems in review remained:

The long delay between implementation and final comments

A lot of questions was asked

Comments from client were in a single list

The Current Workflow

Immediate (or almost immediate) comments on change

Client reviews also one change instead of all changes in singledelivery

The workflow has worked well even for team of 15 vincitizens

The Current WorkflowResults From Review

Practically no remaining coding style issues in client review

Developers have become more disciplined

Client can review the change faster and easier than before

Client can concentrate on functionality

We have started talking that a change is ready to be bashed(”valmis lytattavaksi” in Finnish)

Overview

Each commit is reviewed separately1

Commit is always reviewed after fixing found issues

Reviewed commit is required to be self-containing

Review is done first internally; client gets review request afterinternal review has passed

1A task may contain more than one commit

Time Spent Reviewing

clearly less than 10% of development time

reviews can be easily done, for example, while compiling

Review Workflow

Reviewed ItemsOur Checklist

Functionality

Coding style

Implementation (code structure / architecture)

Readability

Commits and commit messages

Commits and commit messagesWhy It Is Important To Review These?

Good commits with good commit messages

are easier to review

are helpful in the future

forces you to think what is reasonable change


There is surprisingly many tools that leverage good commits. Forexample:

VCS log

VCS blame (who changed a line and in which commit)

find change introducing a bug

Reviewing Commit Messages

say what was changed

explain why the change has been done2

have description of the old incorrect behaviour in case ofbugfix3

2just like good comments3or reference to the bug which contains the information

Reviewing Commit

self-containing

a good chapter in the story of the software’s history

would be reasonable piece to revert

Fixing Found Issues

The commit containing issues is replaced with fixed commitbecause if the issue is found at code review

the story of the software’s history contains less issues / bugs

the commits remain self-containing and atomic

No commit should be broken

Continuous Integration

Usually C.I. is run for changes already put in main branch to

find if bad change has been merged

automatically build test versions

Downsides are that

C.I. is only reacting to issues not preventing them

C.I. could provide valuable information for reviews

Continuous Integration Reviews Our Commits!

Our C.I. tool reviews all the commits immediately after thecommits are available for review by

running unittests

running smoke test

running static code analyzer

building the most important builds

What Else Could Be Done At Review Time

Build and publish test version for all platforms

Have test engineer, client or end user to verify that thechange is valid

About Tools

All the tools we use in the review process

are open source

are quite easy to setup4

require very little maintenance

have been scaling without issues

4first usable installation done less than one day

Version Control SystemGit (http://git-scm.com/)

Distributed VCS

Very efficient at branching

Fast and efficient

Git allows easy way to ”rewrite history” (rebasing).

Currently only Mercurial supports rebasing in addition to Git.Darcs has rebase support in early phase.

http://git-scm.com/

Code Review ToolGerrit (https://code.google.com/p/gerrit/)

Web based code review tool

Integrates with git5

Easy to add comments for changes

A Quick Introduction To Gerrit:http://gerrit-documentation.googlecode.com/svn/

Documentation/2.6/intro-quick.html

5Gerrit implements git repository

https://code.google.com/p/gerrit/

http://gerrit-documentation.googlecode.com/svn/Documentation/2.6/intro-quick.html

http://gerrit-documentation.googlecode.com/svn/Documentation/2.6/intro-quick.html

GerritReviewing A Commit

GerritReviewing A Fixed Commit

GerritMy Comments

The best review tool I have used

Very efficient and helpfull; makes reviewing easy

Just a tool

Continuous IntegrationBuildbot (http://buildbot.net/)

Python based CI system

Master controls which builds should be built and when

Slaves do the actual builds

Built-in support for gerrit

Can be configured to review changes in gerrit

http://buildbot.net/

Outline



3 Summary

Summary



About The Project

Workflow


Tools

3 Summary

Questions?

Improving Code Quality In MedicalSoftware Through Code Reviews

Janne [email protected]

Improving Code Quality In Medical Software Through Code ... · The way how things are done has...

Documents

Transcript of Improving Code Quality In Medical Software Through Code ... · The way how things are done has...