Continuous Reviews for Clean Code Delivery – I

It is often written as one task in the plan each for the review of requirements, design, coding, build, etc. In actual practice mostly reviews are tracked over the emails and some times done for the sake of tick in the box. Code reviews are skipped usually with reason that build-testing or any some testing will do the job of reviews by detecting the defects, and effort to do code review is perceived as “waste”. Now a days, there are multiple code quality tools available in the market which has simplified that task of checking 100s of rules at click of a button, which was not possible even to think otherwise a simple manual code review

Rigor of the code review determines the culture of the organization

Here you will find few good read sources on the code reviews and the examples of code reviews building the culture, there by clean code delivery.

Lets first ask why code reviews ?

Fixing defects at source -> Clean Code -> Increased Quality builds -> Increased Quality Delivery

What should be reviewed. Is it only code ?

More importantly, focus given in the article is for Clean Code. However reviews should be extended to user story readiness including estimates(T-Shirt or any other estimates), architecture, environment readiness, sprint reviews are also review & acceptance by Product Owner, etc.

Effect of Reviews on Code Quality

The effects of fixing code quality issues on predictability and quality. The point here is, monitoring and fixing code quality issues is something that is proven to raise the quality of your application AND your ability to deliver that application to stakeholders on time. But it’s clear that the vast majority of developers aren’t taking full advantage of tools designed to improve app quality


Do developers really practice code reviews. Survey by Rebellabs shows that only of about 2% of teams do multiple code reviews for all commits. This is mirror of quality of the builds that gets deployed to customer site. No matter how much automation is done, if no code review is not effective, there are chances of high technical debt and low maintainability of the code. Change management complexity of directly proportional.


Around 51% of them, do not either monitor or fix the issues / defects reported. So what good of review.

Recommended, identify new issues early in the process and prevent your product/ code from being affected. Keep technical debt under control and focus development time on what matters. Evaluate of tool helps you in the review. Investment on the tool is good, but if not used right tool or tracked for improvements , as good as no reviews.

Code Review tools

Automatically identify issues through static code analysis. Get notified on security issues, code coverage, code duplication and code complexity in every commit and pull request

  • Atlassian’s Crucible is the big commercial success (Git, Mercurial, Subversion and Perforce)
  • ReviewBoard (open source & for Subversion, Git, Mercurial, Bazaar, Perforce, ClearCase & Plastic)
  • Phabricator (open source & for Git, Mercurial and Subversion)
  • Collaborator” (commercial for – Git, Mercurial, Subversion, ClearCase, Perforce and TFS)
  • Codecy ( commercial for Github, Bitbucket )

A successful review requires balance between processes & collaborative encouraging environment.

  • Using a static code review tools and dynamic code review tools [more]
  • Foster a positive code review culture
  • Automate the process
  • Enable clean code check-in for every developer, by integrating code analysis tool for the check-in process. Eg: TFS gated checkins; Github & Bitbucket have inbuilt code review mechanisms
  • Annotate the code and encourage lightweight code reviews
  • Have Security code reviews also enabled atleast at build level
  • Enable tool based reviews at individual, build and system level

Top Benefits of Code Review


Lessons From Google: How Code Reviews Build Company Culture

Employing lightweight, tool-based code review of code changes (aka modern code review) has become the norm for a wide variety of open-source and industrial systems. In this paper, an exploratory investigation of modern code review at Google. Google introduced code review early on and evolved it over the years; study sheds light on why Google introduced this practice and analyzes its current status, after the process has been refined through decades of code changes and millions of code reviews. By means of 12 interviews, a survey with 44 respondents, and the analysis of review logs for 9 million reviewed changes, this investigate motivations behind code review at Google, current practices, and developers’ satisfaction and challenges.

Driving the Future With Design Prove-Its

Bruce Johnson, co-founder and COO at FullStory, created the Prove-It framework. Design Prove-Its define a path forward and occur right before the build phase of a typical product development cycle. The idea is to take in all the signal from customers, prospects, coworkers, and research to produce a clear, tangible, and implementable vision of the future.

Culture, tools, best practices or lessons learnt – Share your story.

Thank You.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s