#iteratia

Grafana - Dashboard for displaying metrics. Suitable for visualizing big data processing applications. Configurable to any set of arbitrary metrics. Open source!

Iteratia.com

Twitter

Facebook

Google+ Page

Even if you are working on a small short-term project, it is very useful to conduct at least one code review to improve the quality of the final result. At the same time, a code review is of paramount importance in long-term development, especially for large enterprise projects, because accumulating code imperfections can lead to disaster. In this article, we'll talk about our experience in organizing the code review process with the help of the Review Board.

Professional development is unthinkable without a regular review of all the updates and changes to the code, which are necessary to detect and correct errors that were overlooked during the development process.

First, this allows us to prevent injection of unwanted changes into the live version of the code; second, it improves the quality of the software product in general; and, finally, it enables developers to improve their skills. It should also be noted that the development team significantly increases the degree of co-ownership of the code thanks to regular discussions.

In large projects, any arbitrary developer cannot be aware of all the details of the project code, because each person is responsible only for a certain part. However, everybody gets to know some general information about the code, as the process of discussion allows each developer to get acquainted with the full codebase. Ultimately, this reduces the risks associated with the possibility of retiring the key developers.

The benefits of introducing a mandatory "Code Review," as one of the tools of quality control, are beyond any doubt. However, do not forget that the review itself requires compliance with certain rules. SmartBear company, in its blog, recounts 11 main points that are worth paying attention to during the code review.

Review less than 200–400 lines of code at a time.

Aim for your inspection rate to be less than 300–500 LOC/hour.

Allow enough time for a proper, slow review, but not more than 60–90 minutes.

Authors should annotate source code before the review begins.

Establish quantifiable goals for the code review and capture metrics to improve your processes.

Checklists substantially improve results for both authors and reviewers.

Verify that defects are actually fixed.

Managers must foster a good code review culture in which finding defects is viewed positively.

Beware of the “Big Brother” effect.

The Ego Effect: At least do some code review, even if you don’t have time to review it all.

Lightweight-style code reviews are efficient, practical, and effective at finding bugs.

Moreover, in one of its infographics entitled, "Code Review Solutions," SmartBear provides some statistics speaking in favor of the Review: the review process costs only 5–10% of the total cost of the whole software project, which is relatively inexpensive; however, finding and fixing bugs at the later stages of software development can be up to 2400% more expensive than correcting the same bugs at the initial stage of development.

In one of its scientific publications, the University of Maryland argues that the process of Review allows developers to find, on average, half of all the bugs in the code.

Today, many different version control systems (VCSs) are used as a central repository for project code (according to the DevProd Report prepared by RebelLabs, the most popular of which are Mercurial, Git, SVN, and CVS). Concerning the order of conducting the code review—either before or after committing it into the VCS—there are 2 main types of code review:

Post-Commit Review: When a senior developer checks code after it falls into the VCS, and, if necessary, makes some corrections—either writes directly in the code what must be corrected or uses special tools, which allow him to view the existing code and post comments to certain lines;

Pre-Commit Review: When changes are reviewed before they are committed into the VCS. In this type of review, the developer prepares all the changes that he is going to introduce in the code, he then sends them to a senior developer for verification, and only after they are reviewed and discussed, the approved changes will be added into the live version of the code.

The Pre-Commit Review approach is effective because it allows you to keep only already checked code in your main repository. However, when using this approach, developers should be prepared for the fact that possible lengthy discussions in the verification process may delay the code getting into the repository.

Modern VCSs rarely support the Pre-Commit Code Review, which is why developers often use third party multifunction programs for these purposes such as, for example, Atlassian Crucible. However, there is a great alternative to such cumbersome programs—Review Board. This program was developed by VMWare team; it is written in Python, it is a very lightweight product, and it can be easily integrated with different free and paid VCSs. The main feature of this program is that setting it up for a particular project takes minimal time, unlike similar heavy programs, which may demand weeks of preparation for a certain project. Moreover, Review Board is available to everyone free of charge—something that cannot be said about, for example, Atlassian Crucible, which, as seen on its official website, the price of the program is rather high.

Review Board is quite easy to use; the main working object here is a review request, which contains a usual diff with the changes, a description of the meaning of these changes, and the indication of reviewers; it also provides a number of helpful optional fields.

Dashboard of “Review Board”

The work with review requests is similar to processing incoming and outgoing messages: a reviewer receives a request for checking the changes from a developer, the reviewer then sends his review back to the developer (which can be interpreted as a response), and the author of the request, in turn, may extend the discussion by leaving comments to the received review. After validating and approving all of the changes, the review request is considered closed and the requester is entitled to inject all his changes into the live version of the code (VCS).

Comment options.

This program allows the reviewer to enter comments at any line of the code being reviewed via a special pop-up form. The option to assign a comment to multiple code lines at once is also supported; it is useful when you need to provide additional context for the discussion. You can use the Markdown markup language in the comments.

Another interesting option is the ability to open issues while reviewing code. While looking through the code under review, a reviewer can leave comments as suggestions or minor improvements. Some of those comments may be critical and require correction before sending the code into the VCS. To mark such critical moments, the reviewer can insert a tick next to the text notes to open an issue. The author of the review request can conveniently browse through all the critical issues and mark them as "fixed" as they are corrected.

Special plugins for integration of Review Board with different IDEs exist; the most popular are ReviewBoard Plugin For NetBeans, A plugin for IntelliJ IDEA to interact with Review Board, and ReviewBoard plugin for Eclipse.

As you can see, Review Board contains all the necessary functions and proves to be quite simple and easy to use.

We are convinced that the introduction of code review has a highly positive impact on both the quality of the code and the general involvement of the team in all aspects of the project. In order to get real benefit from this without increasing the bureaucracy, it is essential to choose the right tool and configure the processes. With the help of Review Board, you can quickly and easily set up the process of code review, whether for small projects or large enterprise systems.

Twitter

Facebook

Google+ Page

Orion IDE 6.0 (the web based IDE from the Eclipse Foundation) was updated. Among a great number of enhancements now it allows editing Markdown. Starting with that update, Orion IDE becomes a mature product, which can be seriously considered as a nice alternative for IDEA or Eclipse in web development. Try the latest version here.

Iteratia.com

Twitter

Facebook

Finally Adobe vouchsafed to produce a tool allowing the designers and the web developers to comfortably work together.

The service is still in beta, but already allows doing a lot of useful things (creating CSS, normal colors, block layouts).

Iteratia.com

Twitter

Facebook

Great introduction explaining the motivation and the basic principles behind React.js by Pete Hunt. Listen to the podcast on CodeWinds.com , and watch the video from the JSConf  .

React.js is a framework for rendering modern web applications. It's the V in MVC for the web, or, as the creators say, It's a rethinking of common practices.

Indeed, React.js uses rather uncommon ideas: abandoning the templates - all markup is done in the code, JS syntax extension for easy creation of this markup, your own virtual DOM. Eventually, this results in an easy-to-understand library, clear application structures and high-speed rendering.

Iteratia.com

Twitter

Facebook