How Code Reviews Shape Culture at CommonBond

Suchi Jain
CommonBond Product & Engineering
4 min readMay 16, 2019

CommonBond Engineers emphasize a lot on code quality. Code reviews are a powerful mean to improve the code quality, establish best practices and to spread knowledge. Adopting this approach has brought a number of benefits to our customers and to our company culture.

So what exactly is Code Review?

This practice involves fellow programmers examining source code they didn’t write & providing feedback which is constructive & critical. This ensures the code is readable, extensible & maintainable. They validate the code against the company’s coding standards.

In addition to peer code review, we also use code reviewing software. SonarQube is one of the tools we use. It is used for continuous code inspection & provides a systematic approach for continuous code quality.

Code review reduces bugs in production
It takes place during the software development phase. This process mitigates the costlier defects that are found right before merging the feature branch to master.

Here, every developer takes a few extra moments to write good quality, maintainable code, address feedback and performs testing on our dev/staging environment before pushing to production. This minimizes time fixing bugs later and, most importantly, spares our customers from developing a negative perception of our product.

Key Benefits

1) Getting better
Every code base is open to being challenged by anyone. We firmly believe that each and every one of us can learn and grow by practicing candid feedback. Every merge request provides us with an opportunity to get better.

2) Promotes High Standards
Engineers learn from each other & share a high set of coding standards. Code reexamination is focused on clean code, reusable, maintainable & extensible in addition to the functional review. This leads to a strong foundation for a project.

3) Recognition
Although the main purpose of the review is to suggest improvements to the code if someone has refactored existing codebase, let’s say utilized generics, highlighted code reusability or removed duplicated code, etc. — we utilize the “+1” as a means of appraising the teammate and delivering kudos.

4) Professional maturity
Sometimes there can be conflicting opinions during peer review. People have different views about the best practice applied (or not). Coming to a productive consensus can sometimes be a challenge. As Avril Lavigne says, “It’s complicated” — but don’t let the song get stuck in your head because of me.

The key point is around how we resolve those kinds of divergent opinions. Practicing a positive and open attitude towards managing divergent opinions improves our skillset as a teammate

What did I learn from code review?

In this particular instance, I want to highlight how I learned new Postgres SQL inbuilt functionality from an astute code review that made the code cleaner, simpler, faster and easier to understand.

So what is Upsert?
Upsert is a combination of insert and update. In simple terms, upsert is to insert rows into a database table if they do not already exist or update them if they do.

I was working on a task around updating the existing code base.
Made following code changes:
* Updated the method signature to add ‘throws exception’
* Removed try catch block
* Updated method to be package protected as it was unnecessary public
* Added unit test in addition to changes around respective calling method

Below is the code snippet before code review:

Received the quick feedback — “check if Postgres has built-in Upsert functionality.” After going through this article realized that PostgresSQL indeed supports built-in upsert functionality.
Made schema changes to add a `UNIQUE` constraint on the column which will be utilized for on conflict clause. Updated SQL queries to use INSERT INTO… ON CONFLICT… syntax & boom!
* No more making multiple trips to the database
* Got rid of if-else
* Clean & maintainable code base

Below are the code changes as a result of feedback:
On Postgres database, to utilize the upsert feature, I used the ‘INSERT ON CONFLICT’ statement :

INSERT INTO <table name> (<column1>, <column1>)
VALUES (<value1>, <value2>)
ON CONFLICT (<column1>)
UPDATE SET
<column2> = <value2>

If you haven’t tried the Upsert PostgreSQL 9.5 feature, feel free to try it out. And thanks to david kirkpatrick for the quick code assessment.

Conclusion

Graydon Hoare said,
“Code Review is the single greatest way of noticing & killing bugs, increasing overall understanding, fixing design problems & learning from one another.”

We agree. Constructive, effective and respectful code review is not only what we believe, but it is also what keeps us aligned with many of our CommonBond values. When we deliver good code, everyone wins.

--

--