“Code Reviews” have been used for decades in software engineering. Historically, the primary focus has been on source code – with developers following a formal process focusing on finding and fixing defects. Over the past few decades, there has been significant movement towards making reviews more agile, less resource-intensive, and applicable to work products other than source code. For those who have participated in successful reviews, the consensus is overwhelming that they are beneficial. Here, we’ll take a look at some of those benefits and some of the review opportunities available during a Salesforce implementation.
Benefits of Reviews
Benefit #1: Improved Quality
As a Salesforce consultant, a primary goal should be high quality – creating robust, correct, usable solutions that are scalable, maintainable, and add value for our customers. Reviews are the most effective tool I know of when working toward that goal. Logically, applying multiple perspectives to a problem results in solutions that are more likely to be correct. In many disciplines, we realize that to err is human and plan accordingly. Consider the number of rewrites, reviews, and edits an author will go through before publishing his final work. As Salesforce consultants, we must realize that we are “authors” and the quality of our work will improve as we seek the input and ideas of our coworkers.
“In a software-maintenance organization, 55 percent of one-line maintenance changes were in error before code reviews were introduced. After reviews were introduced, only 2 percent of the changes were in error. When all changes were considered, 95 percent were correct the first time after reviews were introduced. Before reviews were introduced, under 20 percent were correct the first time.”
~ Steve McConnell
Benefit #2: Skill Building
While improving the quality of our work, reviews will also spread domain knowledge and improve consulting skills. A brief review of a requirements document or data flow diagram can help communicate details that might otherwise be tough to uncover. As a developer, I can’t count the number of tips and tricks I’ve learned by reviewing others’ code. Code reviews help build productive and skillful programmers.
Benefit #3: Communication
Last but not least, reviews are a very effective way to communicate domain and project information among team members. Reviewing work products such as source code, workflow rules, or test scripts helps to communicate details at the lowest level. Team mates who analyze each others’ work will understand the “big picture” better and produce a more consistent implementation.
Review Methods
There are several review methods. Find one that fits the way your team works and implement it!
- Formal (Fagan)
This is a careful and detailed process with multiple participants and multiple phases. Formal reviews are the traditional method, in which co workers attend a series of meetings and review line by line, usually using printed copies of the material. Formal inspections are extremely thorough and have been proven effective at finding defects, but also take significant time. - Over the shoulder
In this method, one person looks over the author’s shoulder as the latter walks through the code. - Email pass around (+ Google Docs)
Here, the author or source code management system emails code to reviewers. - Pair programming (online tools)
“Pair programming” was introduced in the “Extreme Programming” methodology, and refers to two authors working together. - Tool assisted
This refers to any process where specialized tools are used in all aspects of the review: collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, and giving product managers and administrators some control over the workflow.
The “Tool Assisted” method works well on Salesforce projects and fits in well with other best practices such as revision control and project management systems. When implemented in a Salesforce team, the process might look something like this:
- Create a branch within the source code repository where the team’s code changes are being stored.
- Edit and test your work in a development or sandbox org.
- Push your changes to the branch in the repository.
- Create a pull request and invite others to participate in the review.
- Reviewers evaluate the work based on related requirements, user stories, and EnablePath standards. They make inline comments and discuss possible solutions. The initial review should be completed within 24 hours.
- If rework is required, the author makes changes and resubmits (back to step 3).
- Once all reviewers have approved the changes, the work is merged into the master branch, where it can be deployed to the target org in the process.
Best Practices
- Keep it small! A good is 200-400 lines of code. This is what most people can review in 60-90 minutes.
- When requesting a review, add documentation so that the design is understandable.
- Take the time! When reviewing someone else’s work, take the time and effort to do a thorough job.
- Keep it positive. Besides pointing out defects, comment on good design and best practices.
- Use checklists
- Iterate (use findings to update checklists)
- Resolve all issues