Would you toil for months to years to write the great American novel, only to ship it off to a printer without an editor? How about publishing a medical paper — the culmination of years of research and testing– without getting a second pair of eyes on it?
Of course not. That’s crazy talk.
It is of this same line of thinking that you should approach your application’s internal code. Software is the sum of its parts and only a thorough and well-managed strategy for writing and maintaining that code can ensure the longevity of your application’s lifespan. Code review is your insurance policy against most issues that would arise in the future due to sloppy implementation or short sided decisions.
Code review is pivotal to a healthy and scalable codebase and should be treated as a top priority among project managers, engineering leads, and CTO’s alike. Most code review is conducted in some form once a pull request has been opened. For those of you unfamiliar with the term, a pull request is a step in the process of managing one’s codebase using version control (Git, SVN, Mercurial, etc.). The actual process entails pulling in prior code, applying the new code changes, and then opening a “request” to merge the new code with the old. Github has provided us in the IT world with indispensable tools for managing the entire workflow surrounding a codebase, often automating much of the processes into the UI itself. However, it is quite important to be as meticulous as possible and go above-and-beyond when it comes to code reviews for the sake of thoroughness.
Thanks to Smartbear’s annual State of Code Review, you have the ability to take a look into the current state of code review in the industry and decide whether you are ahead of the pack when it comes to assessing your application’s functionality prior to deployment or sorely lacking in areas that can be addressed for your software’s well-being.
Code review is not only used to make sure that small, unnoticed errors don’t make their way into your deployed application, although that is definitely an important facet of the process. Often, even the best developers can get caught up in the moment of producing code and miss small mistakes that might otherwise be noticed.
Another important reason for implementing an organization-wide protocol for code review is that it actually plays a role in strengthening everyone’s understanding as a whole. Those being reviewed often learn new tips and tactics to take with them for future work, and those reviewing the code learn new things to look for that they may have previously not known about. Add to that the fact that it helps developers and lead engineers get a look at parts of the codebase they may not have worked on themselves, and all of a sudden you’ve got a tool that is mutually beneficial for both the reviewer and the developer being reviewed.
Never underestimate how important it is to become more familiarized with parts of an application that you were unfamiliar with before. It will aid in any future work a developer contributes to that ties into other pieces of the software that may need scaling later. Many times it is only senior members of a development team that will get a chance to oversee large portions of the code in an application, but that knowledge can prove incredibly helpful for all contributing developers, both for their future work on the codebase and for their overall understanding of software engineering.
The State of Code Review 2019
Available now, Smartbear’s State of Code Review in 2019 is their 6th annual survey of developers and their code review processes. They surveyed over 1,100 software professionals about code review frequency, tool usage, and code quality satisfaction, to how fast teams are transitioning to Git and other software management tools.
Unsurprisingly, for the 4th consecutive year, developers answered that code review was the #1 thing a company could do to improve code quality, beating out unit testing and continuous integration. Improved software quality, sharing knowledge across all development teams, and mentoring less-experienced engineers were the top reasons why software engineers felt so strongly about the need for extensive code review. 4 in 5 developers answered that they learn from others in code review sessions, backing up the assertation that shared knowledge is a major factor in code reviews.
Version control plays a huge role in any modern development environment, and Github continues its dominance in that field with 67% of respondents saying that they control their codebase with the Octocat. BitBucket and Gitlab round out the next most popular offerings and only 9% of respondents report that they are using no repository management tools.
Integrated development environments (IDEs) have come a long way when it comes to code review, bringing review tools built directly into their interface. When coupled with version control management extensions as well, many teams can do their entire code review process inside of their IDE of choice. Microsoft’s Visual Studio Code took the top place among those surveyed with 47% of developers saying they use the development editor daily.
Requirements management is perhaps the biggest tool to help ease the burden of complicated code review scheduling. Atlassian’s JIRA remains the dominant tool for tracking bugs, with 65% of those surveyed saying they use the platform. Trello, a more Kanban-esque entry in management platforms, came in with 13% of respondents saying they used it for bug tracking and managing the code review process.
Finally, of those that perform daily code reviews, 53% responded that they were happy with the process, while only 32% responded that they did not enjoy the reviews taking place on a daily basis. While tedious, code reviews that take place daily can ensure that everyone on a dev team is on the same page, which can contribute to overall satisfaction at their job demonstrated here.
Here at Kloudless, we are probably about as thorough with our code review processes as any tech company, especially one of our size. We implement a rigorous testing suite into our pull requests on Gitlab and adhere to strict linting guidelines based on the Airbnb style guide. On top of all of this, we have 2-3 of our engineering staff review all pull requests before merging in the aim of getting as many eyes on the code as possible before it is implemented into our software.
Things like modularity, scalability, and efficiency are all considered when doing our code reviews here. We find that this strict approach not only ensures that we keep our Unified APIs as bug-free and healthy as possible but also help to train and educate our engineers in best practices and methods to aid them in their own future development.
Help Us Help You
All code your developers produce and plan on merging into your deployed codebase should be gone over with a fine-tooth comb. You can, however, make your life easier by lessening the actual code necessary to write in order to get your desired functionality. With Kloudless Unified APIs, your developers can code once and integrate many, cutting down the lines of code by a factor of however many API integrations your application needs. Getting set up with 5-6 cloud storage services is as easy as getting set up with a single one, so your code review can stay short and manageable while getting as much functionality as your codebase needs to satisfy your userbase.