LAUNCH Pantheon Announces New Levels of Automation with Autopilot Get Access

The Definitive Guide to Agency Optimization

 Two Thumbs Up: Code & QA Review Processes

Review processes are a vital part of a streamlined workflow. They keep the project moving and improving. They make sure you deliver what you promised to deliver. And, thankfully, they allow you to reach the end of the project that satisfies everyone involved (Whew!).

Reviews should happen proactively—throughout the project’s lifecycle—and should include a synchronized process for shipping code, a streamlined method for testing the code, and client participation to nip any issues in the bud sooner rather than later. It’s also important to note that you can't do reliable review and QA unless you have a reliable workflow. The most important foundation of QA is that you have a "known state", which means that everyone is clear about what exactly it is that you are reviewing. Otherwise, you are investing time and resources to giving feedback to a snowflake right before it melts and disappears forever.

There are four stages to a solid review process:

1. Automated Testing 

Generally, code review happens only after automated testing. It's not efficient for a human to review code that is not yet up to the robots' standards. QA can be automated with tools and services like automated testing, visual regression, code level tests, automated browser testing, etc. But don’t miss out on simple, quick wins like automated syntax checking and code linting. These take only minutes to configure in most modern code editors, and can cumulatively save many developer hours over a month. Make the robots do the work!

2. Code Review

Standardizing on a set process for internal code review is the best way to maintain your agency’s code standards and prevent problematic or difficult to maintain code from being deployed. Setting a standard process that is replicated from project to project allows your team to work together more efficiently and cross-pollinate, avoiding roadblocks along the way. If another developer has to work on the project in the future, they’ll know what’s going on. Don’t reinvent the wheel, ensure quality code.    

It is common practice for teams to use pull requests into a repository as an opportunity for peer and/or robot review. Many teams establish norms whereby no pull request can be merged without first getting a plus one (perhaps in the form of an emoji) from one of their team members. Teams also enforce these norms in different ways. You might choose to block members from pushing directly into master or limit who can merge to master. The important thing is that someone other than the person who wrote the code has an opportunity to ask questions, share their insights or learn something themselves. Taking it to the next level, you might choose to get robots involved. Leveraging a CI tool (such as CircleCI, Travis, or Jenkins), code complexity, syntax reviews, and basic linting can give feedback that is onerous for a human looking at the code to provide.

Matt Johnson

Matt Johnson, CTO, Alley Interactive

Our peer code review follows a sort of honor code. If you don’t know x language very well, you don’t review that code. This ensures that our process is efficient, since the team member reviewing your code is well versed in how it should look and act. It also fits our company culture—we don’t have a hierarchy. Partners get code reviewed just the same as any other team member. The code review is not an adversarial thing, but rather a learning experience for both the reviewer and the reviewee.

Learn more about Alley’s peer code review >

3. Internal QA

After the code review, bring your team members together to make sure everything works. The purpose of QA is to ensure that you have delivered code that meets the requirements. It's pedantic but helpful to avoid the word "test" in this context. Use "checking" instead. To this end, you need to check that your code meets the parameters of the project. That might mean you use a tool to check for accessibility, for site speed, for behavior, and/or for its visibility on specific browsers or devices. This is not the same as testing. It's making sure you are delivering what you said you would deliver.

4. Client Review

Make sure you do code review and internal QA first, and after YOU think you’re done, share with client and ask for feedback. Give a deadline and set expectations. It is important that the client understands and accepts their responsibility to test the code. You, as a developer, will deliver a feature that meets the client's requirements. It is the client's responsibility to ensure that they have specified the requirements fully.

Sometimes developers misinterpret requirements, but it often happens that seeing something "alive" is a learning experience for the client, which may lead to a revision of the requirements. This is why having an Agile process is a huge help. Rather than a red-marker style activity of clicking through a site and comparing it to a set of static comps, this can be a great time for collaboration.

Depending on your process, you may have a few rounds of review, but be clear on what kind of feedback you’re looking for. If you keep it open-ended, don’t be surprised if they ask for a full virtual reality implementation, or to have all the images replaced with rotating cat .gifs.

Mike Bal

Mike Bal, Associate Director of Client Delivery, 10up

It’s important to step back from projects as a whole and take a magnified view of different parts along the way. Being able to see and evaluate how all of the individual pieces of a project work together is a vital part of finishing the entire project successfully.

Code reviews provide an extra level of quality assurance from an engineering perspective, while helping to keep the team on the same page. An additional benefit of these reviews is giving less experienced engineers an opportunity to review more senior level code, coupled with direct coaching and feedback on the approach.

Client review ensures that we haven’t misunderstood or overlooked anything during the requirements gathering process. It also gives clients an opportunity to experience our interpretation of their initial request and make sure both parties understand what is being built. Testing gives us an additional interaction to fine-tune how best to meet the clients’ needs.

An Agency’s Most Valuable Tool

Pantheon lets you do more with your resources. The platform is absolutely free for agencies—just invite clients to pay when their sites go live.

Let’s get in touch