www.devoxx.com

www.devoxx.com

Effective code reviews in agile teams

Wojciech SeligaSenior SW DeveloperAtlassian

Sławomir GinterSenior SW Developer & CSMSPARTEZ

www.devoxx.com

Overall Presentation Goal

Share our observations on lightweight code reviews. Gather feedback and discuss it.

www.devoxx.com4

About us

• Wojciech Seliga is a software developer working for Atlassian on IDE Connectors. He is also a co-founder of SPARTEZ - agile and Java consultancy. For many years Wojciech has been fostering agile practices, introducing collaboration tools and developing mission-critical software systems.

• Sławomir Ginter is a software developer at Atlassian working on Clover integration with IDEs. He is also a co-founder of SPARTEZ. Sławomir is a certified ScrumMaster. He has many years of experience in embedded systems and Java.

www.devoxx.com

Does code review make sense?

Can we prove its value or lack thereof?

Pair programming or code review?

www.devoxx.com6

Obvious(?) pros and cons of code reviews

Top 5 ways to make reviews better

How we at Atlassian perform code reviews

Non-obvious aspects of code reviews

Problems we have with code reviews

Demo - code review with Atlassian Crucible web UI

Demo - code review with Atlassian IntelliJ Connector

Q&A, open discussion, your feedback

Agenda

www.devoxx.com7

Introducing people to the code

• used style/conventions

• design

• reusable components

Mentoring junior developers

Sharing good engineering practices

Spotting bugs earlier

Fostering collective code ownership

Reasons for doing code reviews

www.devoxx.com8

Time-consuming

Risk of flame-wars and animosities

Disrupting for developers

Possible bottlenecks (e.g. all reviews go to tech lead)

Still no guarantee for spotting all the bugs

Often rejected or dropped due to tediousness

Code reviews vs. pair programming

Reasons for avoiding code reviews

www.devoxx.com9

Requires synchronization from all reviewers

Super tedious

Too much emphasis on the structure and the workflow

Often the same code is reviewed many times

Why traditional code review sucks

www.devoxx.com10

Make it asynchronous

Make it lightweight - simple process

Provide efficient tool support

Make it diff-oriented whenever applicable (in most cases)

Make it transparent and persistent

Top 5 ways to make code review better

www.devoxx.com11

Every team has its own rules - self-organization

But usually:

We use simple Crucible workflow and its terminology

All new people on team create review for every commit

Tech leads monitor commits, review diffs and raise reviews when required

Moderator = Author OR Moderator = Tech lead

Reviewers = well-known pack of fellows (per project/component)

Allow anyone to join your reviews

Raise one review per day, try to complete pending reviews within one day

Post-commit OR pre-commit review

Code review at Atlassian

www.devoxx.com12

Facilitation of distributed teams (including outsourcing & offshoring)

Collaboration on low level design

Code review is typically easier to introduce than pair-programming (less resistance in the organization)

Time-zone difference may work for you: code during the day, create review in the evening, have your review completed by next morning

Knowledge Base - tricks, do's, dont's, handling proprietary APIs

More advantages...

www.devoxx.com13

Hanging reviews

Re-reviews, tracking defects and their resolution

Sometimes flame-wars are unavoidable...

Storm of notifications

Addressed vs. unaddressed changes/comments/replies

Too much focus on diffs (tempting)

Problems we have

www.devoxx.com

DEMO

Creating and performing code review using

Atlassian Crucible web UI

www.devoxx.com

DEMO

Creating and performing code review from IDE using

Atlassian IntelliJ Connector connected to Crucible

www.devoxx.com

Q&A

• What do you think

www.devoxx.com

Thanks for your attention!

Atlassian Cruciblehttp://www.atlassian.com/software/crucible/

Atlassian IDE Connectorhttp://www.atlassian.com/software/ideconnector/