Home / Code Review with Pull requests

Code Review with Pull requests

“You say Pull Requests! I say Streamlined Code Reviews! ???”

Code Reviews – Hmm... The Hoopla!!!
Every development team knows how absolutely essential and remarkably significant code reviews are to the quality of code that is delivered. Yet, code reviews can be reminiscent to many developers of commotion, hassles, bugs, lack of accountability; just to name a few! Most teams, as efficient as they claim to be always plead guilty in this regard. Sounds strange, yet painfully true! Wonder Why?

Code Reviews, when streamlined can be a boon to development teams. Even the best developer out there should always believe that there is room for improvement; precisely what code reviews should accomplish. But, why do so many of the code reviews result in poor quality code? Why do we still find critical bugs on the release day or better yet, after delivery? The answer my friends, lies in a simple word called “STREAMLINE”!

To most of us, Code review is nothing but a process of designating a few individuals other than the author of the code, to look over and review the code changes and provide their input and approval on the same. Simple yet complicated, why? Well, I have a few theories:

• Code reviews are usually pushed to be conducted towards the end of the development cycle, which in all probability will lead to the overlooking of many crucial aspects.
• Too many lines of code are kept available for review. Due to the size of the code, developers feel compelled to assign more number of reviewers. This is Mutiny! Not all members in the team have the necessary bandwidth to give in a 100% while reviewing.
• Lack of accountability with the reviewers: Without streamlining the code review process, the reviewers don’t necessarily feel accountable about the task at hand, more so when there are multiple reviewers. Well, it’s only human to believe that the other reviewer did a thorough job! Phew!!! This behavior is typical of large development teams.
• The change might be small but can possibly have severe implications on the entire workflow. But, many reviewers don’t always check the entire workflow of the code to identify possible discrepancies and errors. I have fallen victim of many such “Code Reviews”.
• Finally, there is the “I am an excellent coder! They have no idea what they’re talking about. They don’t know the functionality like I do”. 


Version control to the rescue, Again!
Over the years, we are familiar with ways that version control tools like Git and SVN help developers and their teams to collaborate and work effectively. Using version control, one can easily branch the section of the code from the main repository and make changes in an independent branch without affecting the entire codebase. Using Git and SVN alone, it is fairly easy to conduct code reviews before merging the changes in the branch into the master. However, with Github, developers can use the option of using ‘Pull Requests’ to create code changes and to also have them reviewed in a more streamlined fashion that makes codes review easier than ever. This helps both the developer and the reviewers to view the change from a stand-alone point of view before they can be merged into the functionality already in place. Once the changes are made, the developer can create a pull request to discuss the changes and have them reviewed too before merging. With the click of a button, the developer can request as many number of reviewers to review and approve the change.

Code reviews offer a forum for constructive discussions over the code changes. Other developers can provide insights and these discussions could perhaps lead to better solutions than what they had started out with originally. Let’s face it; we all know two heads are better than one when it comes to discovering the number of possibilities there can be.

Streamlining code reviews eliminates the commotion that is usually associated with them. Pull requests also add visibility to this process, ensuring that a log is maintained of every commit and comment that is made, including differences of opinions. It helps with project management and collaborative development. Well, the crux of the matter is that Pull Request is not just another way of conducting code reviews; it is much more than that!

Tags: 

Reactie toevoegen

Plain text

  • Geen HTML toegestaan.
  • Adressen van webpagina's en e-mailadressen worden automatisch naar links omgezet.
  • Regels en alinea's worden automatisch gesplitst.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Adressen van webpagina's en e-mailadressen worden automatisch naar links omgezet.
  • Toegelaten HTML-tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Regels en alinea's worden automatisch gesplitst.
Bij het indienen van dit fomulier gaat u akkoord met het privacybeleid van Mollom.