Behind the Scenes of Your Software Development Project: Cracking Code Reviews
Our company’s best practices help us to be intentional about quality. They provide us with a framework for proactively solving problems before you even know they exist. Effective code reviews are just one of those behind-the-scenes best practices that you probably don’t notice is there, but you would certainly notice if it were gone.
What is a Code Review?
A code review is a meeting between developers and their peers or superiors to carefully examine a piece of code together and problem solve any issues with the code in real time and with the benefit of multiple perspectives.
As your team of Praxent developers creates new features for your custom software, they are writing code, testing it, and refining it over and over as they go. Conducting effective code reviews are just one of the ways we are highly intentional about catching mistakes and improving every detail of every feature throughout the software development process.
>> Learn more about the software development lifecycle in our article on agile software development.
Usually right before we’re about to finish a sprint, the developer working on a particular feature will want a second pair of eyes to go through the code and make sure it’s the best it can be. He or she will coordinate with, say, Eddie, one of our front-end developers, and maybe Sam, as well, our director of engineering. They’ll all get together and stare at the code over the developer’s shoulder, scratching their chins, much like these hovering art directors. (Just kidding!)
Effective Code Reviews: 5 Core Pillars of Success
During code reviews, we’re examining how well the code adheres to five core pillars of success:
1. Performance
The first thing we do in a code review is run the feature and make sure it executes correctly. If there are any functional problems with the code and it doesn’t run properly, the reviewers and developer will work to identify the problem and solution.
We don’t settle on performance. Instead, we test the code for every imaginable situation. You might think the code is ready to go, but what happens when the user inputs a number that’s 10x higher than your code was built to handle, for example?
2. Readability
When developers write code on their own, they usually produce something that’s in a style unique to them. The problem with this is that other developers are not likely to understand the code, and the developer who wrote it may not even understand it several months from now.
Good, readable code can be understood by reading the variable names and function names in light of the code’s general structure. It should be fairly easy for any developer to conceptualize and reason about what the code is supposed to be doing.
Code reviews help make a developer’s personal style readable by other developers. If Eddie and Sam read the code and can’t understand it as easily as the author, then they will help the developer identify opportunities to revise for better readability.
3. Maintainability
Maintainability refers to how easily the developer will be able to make changes to the code in the future.
During a code review, we’re thinking, “How hard is it going to be to change this later if I need to, and is there anything we can do to keep it clean, today, to make future maintenance smoother?”
4. Security
Code reviewers are looking for security holes in the code. A security hole is anything in the code that should not be shared, such as passwords. Additionally, they are looking for any areas that could potentially cause a security problem.
For example, we always check for string safety anytime code is accepting input from a user, like when typing a name into a form. Potentially, a hacker could try to pull a fast one on the form. If the code has not been checked for string safety, then the form won’t be programmed to handle the situation, inspect the input, and reject it if it’s bad. That would be a potentially dangerous security hole that can be prevented if identified during a code review.
5. Formatting and style
When a team starts a project, they agree on standards for how the code should be formatted and styled. Code reviews provide an opportunity to run through the code, checking for compliance to those standards.
At this stage we will also look for simple errors, such as erroneous dates or time zones; numbers that could be bigger, negative, or zero; and misspelled names. The goal is to end with a piece of code that can recover gracefully when users interact with the feature in an unexpected way.
What You Can Learn about a Software Company from Their Code Reviews
A company’s code reviews reveal a lot about their culture, values, and general approach to problem-solving.
Companies with a healthy work environment, dedicated and passionate developers, supportive leadership, and a commitment to long-term results over short-term gain usually have effective code reviews that look like this:
- Each person involved in the code review walks away with some new knowledge or insight. They are excited and energized by the experience. They enjoy honing their craft and making it better, so code reviews are something they look forward to.
- Code reviews help spread knowledge around the team as developers learn from each other. This happens organically as more experienced reviewers demonstrate new techniques, functions, and approaches to problem-solving in real time.
- As a result of the review, the quality of the code improves significantly and the developer catches errors that might have otherwise been missed.
Unfortunately, some developers have experienced code reviews that look more like this:
- Code reviews are demoralizing blaming sessions. They are an opportunity for one developer to tell another developer that their work is bad and they are not intelligent.
- Code reviews are mandated by the company. When, how, and with whom they happen is determined beforehand for the developers. Oftentimes, this occurs in a work environment where developers lack maturity or management hasn’t released developers to take ownership of their work.The developers don’t have permission to take initiative, be proactive, and own the problem solving that needs to happen for their features to be the best they can be.
- Rather than being a time of learning for passionate developers who enjoy their jobs, these code reviews may look like boring “Office Space” meetings. The people involved aren’t interested or excited but are just going through the motions. They aren’t engaged or bringing their opinions and minds to the table. They are just following orders.
At Praxent, we are a supremely solution-oriented group of problem solvers. We are more interested in the long-term success of what we’re building than in short-term gains. We recognize that in new product development, it’s not about the technology, it’s about the outcome. This is why we don’t get caught up in technology for its own sake — or code reviews for their own sake.
Our team is made of professionals like Sam and Eddie who are passionate about what they do. They care about their work and they care about the end result.