View
5.375
Download
2
Category
Preview:
DESCRIPTION
slides supporting the talk we gave at a BOF during Devoxx 2008 conference
Citation preview
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/
Recommended