#

Nikhil VazeSenior Software Engineer

You Live, You Learn, Then You Get Perforce Swarm

#

Nikhil VazeSenior Software EngineerElectric Cloud

Nikhil Vaze is a Senior Software Engineer on the Electric Cloud engineering team. He is a full stack engineer and loves to hack on things. Nikhil holds a Bachelor of Science in Computer Engineering and Master of Science in Security Informatics from Johns Hopkins University.

(Speaker photo here)

#

• Case study from Electric Cloud, ElectricCommander Engineering– Our initial code review policy– How it evolved– Our current setup

• Spoiler Alert: We use Swarm

– Demo!

Talk Overview

#

• Code reviews are a Good Thing™– Spread knowledge around the team

• Senior members review new team members contributions• New team members speak up when something is not clear

Assumptions

– Catch problems earlier in the development cycle.

– Enforcement of code style and coding standards.

#

• Creator of Python describing code review policies• http://

java.dzone.com/articles/how-google-does-code-review• “Because the general rule with bugs is always: the sooner

you find them the better.”

For skeptics

• John Graham-Cumming’s view on code review• http://blog.cloudflare.com/making-code-better-with-reviews• “All our code goes through this type of process to improve

its quality and security, and it's an essential part of our PCI certification.”

#

You live: Our life before code review

#

Code reviews? I’m too busy!

Photo Credit: Unknown, found via @shaynecuffy

#

• All engineers were in one room, on the same schedule– Code reviews done informally by calling someone over

to your desk

Code reviews were ad hoc

• Since the team was small, this worked to a point.

#

• When we forgot to ask someone to come to our desk…– “I wish I had asked for your guidance when I coded this

up two weeks ago.”– “I saw your commit, did you think of xyz condition?”– “How was this code checked in??”

Led to some ‘forehead slapping’

#

You learn part 1: How and why we rolled out formal code review

#

• Company grew, we started hiring people globally– Suddenly our beloved development practices that

worked so well started showing problems

Formal process for code review

• Standardized on another tool (Swarm was not yet released)– Documented it on the wiki

• And then we…

#

Celebrate! We have code review!

#

• How does someone create a review?

Not so fast…

#

• …kind of painful. Need your dig out your good luck charm to successfully create a review

Code review good for you but

• On the other hand, some teams loved the tool we chose and had no complaints

• Some people p4 shelved and shot an IM for the review process

#

You learn part 2: How we learned about Swarm

#

• Swarm Hackathon– It’s on a boat!

• Let’s have some fun

How did we find out about Swarm?

#

• A group of people form teams and work for a constrained amount of time on a small project.– Usually there is a theme uniting all projects– Usually outside of work hours– Sometimes there are prizes

What is a hackathon?

#

• We did pretty well and EC-Swarm was born!

Result:

#

Then you get Perforce Swarm

#

• We were using it anyway to perform reviews. If there was only a tool …

p4 shelve was our friend

#

• Versioned code reviews– Reviewers can make suggestions and then ask the

author to reshelve the files to review them again.

Enter Perforce Swarm

• Ability to commit code from the Swarm UI. – Geographically distributed teams can hand off code and

commit on each others behalf

• Ability to combine test output with the code review

#

Demo!

#

• You will still have bugs in code that has been reviewed

Code review lessons learned

• Consistent use and discipline of code review have caught errors

• Treat code reviews as high priority because they can be become a bottleneck– Respond to them quickly, ideally within your workday

• Be constructive

#

Use Swarm!

Code review lessons learned (cont)

(And ElectricCommander ^_^ )

##

Thank you!Nikhil Vaze@therealnikhil