I am curious about how infrequent automated code reviews seem to be in the workplace. As software?developers, we pride ourselves on our ability to automate?away other people’s problems. Much of what we do is scrutinizing manual work done?by our customers?or business?stakeholders. We find tasks that could be performed more efficiently, automate them, and the customer hopefully praises our efforts.
Yet it seems?that we rarely scrutinize our own work. Manual code reviews run rampant on many software teams. We take our “expert opinion” and turn it into either a mental or written checklist. Then we apply the checklist through manual labor, looking over one file at a time. Oftentimes we miss things; perhaps we’re tired or distracted by other tasks.
Why not do to our own processes what we do to others: automate them? After all, computers will be better at handling some of these checklist items than we are.
Why Are Code Reviews Still Manual?
Why do we do this to ourselves? As automation specialists, why have we turned a blind eye towards our code reviews?
In some cases, it’s a simple lack of awareness of the various tools that exist?to automate these things. Yet exist they do, usually under the header of static analysis. And for those who are aware, you may think, “OK, but how do I automate my reviews?” Perhaps you don’t have a fleshed-out checklist of code reviews. If that’s the case, I have a few simple things you can do using tools like CodeIt.Right to automate pieces of your review.
You Don’t Have to Automate Everything
You may think that if you can’t automate the whole review process, what’s the point? But even automating some of it will give you value, which is why I mentioned automating?pieces. Just like when we build a minimum viable product of our software, starting with simple gains in our code reviews will help us gain traction. It will help increase your team’s confidence that automating works.
Think of it this way: you can automate the more mundane parts of your review away and focus your energy on the more interesting parts. The automated code is like a seeing-eye dog, helping you better use your talents and perform your job. Even if it can’t detect all problems, it can point you in the right direction. That way, you’re not wasting time pouring over dozens of files.
Here’s What’s Easy to Automate
So I want to bring some manual checks you can automate to your attention. I don’t expect that these will completely replace your processes, but thinking about automating these checks will set you on the right path.
1. Your Method Is Too Long
A simple guideline when designing readable, clean code is to keep your methods short. By short, we mean a small number of lines of code. By keeping methods short, you are likely to produce a lot of little methods, each one describing what it does. This reduces the overall noise of the class by compartmentalizing all the chunks of work. Ideally, these methods read like a story, starting with a table of contents and working down from subheading to paragraph.
You and your team can decide how long is too long. I have heard a preference for as little as five lines. I have trouble following that one myself, but your mileage may vary.
Once you pick a desired length, your static analysis tool will then scan all your methods, looking for any that are over your determined limit. It’s likely to ignore empty lines and comments. This is much faster than having to manually run through all the methods in a 5-10 file code change and count the lines on each method.
2. You Have Too Many Methods on a Class
There is a principle in software called single responsibility. It states we want the various methods and classes of our system to be small and focused on one thing. Often this responsibility is aligned with the business outcome for which our system is striving. This lets us easily find the code we need to touch when changing business rules.
However, we easily blur the lines of responsibility for our classes. We end up with these God classes and can’t figure out what they’re supposed to be doing because they look like they do everything.
Since methods represent the responsibilities of most classes, we can look at how many methods a class has to see if it is becoming too godlike.?We can automate checks for this by establishing a max method count for our tool to identify per class. To avoid false positives, we will ignore getters and setters; they aren’t behavioral methods. How many methods you feel is too much is up to you and your team.?
Trying to count methods on a class manually will take quite a while. Also, this sort of check is something that we get desensitized to over time; we will likely start “skipping classes” in order to save our precious time.
3. Your Class Dependencies Are Nested Too Deep
The farther down a chain of classes we need to look when coding, the harder it is to know what business outcome the code is trying to achieve. It can also be harder to figure out where to make a particular change. For example, I have a web controller to submit a purchase order, so I have a purchase order service. But that service needs a product service as one of its fields. And the product service needs a product formatter. Finally, the product formatter needs a string formatter utility to do its work. That’s quite a few classes (and I’ve seen much worse examples than this one.)
Your automated code review can check the dependency graph of your classes. If you see one go over five levels of dependency, it may be prudent to call that out. Maybe you want to give it as a warning, not necessarily an error. Then you can investigate why there is such a deep nest of classes and make the judgment call for yourself.
4. Your Class Has Too Many Dependencies
Similar to the nesting mentioned, classes can also have too many direct dependencies. If you see a class or method that needs a bunch of other classes to do its job, it may be breaking the single responsibility principle.
Your tool can easily scan the fields or constructor and check this. You can make a rule that a class cannot use more than five other classes to do its job This will encourage developers to think about how to abstract away logic that does not need to be directly in the parent class.
5. Your Variable Names Are Too Short
The final check I will mention is one that at first seems silly. I think it is worth it to check if variable names are too short. This is a very simple check that can have a profound impact on your code. It is common for developers to use one letter or meaningless variable names like “res,” “temp,” etc. as they bang through their features. These names do not express their intent very well.
A simple way to encourage more thoughtful naming is to ensure developers cannot use these one-to-three-letter variable names that are useless. This is no silver bullet, but it can be enough for a developer to pause and say, “Yeah, I should put more thought into this.”
Let’s Automate That Code
One of the main values of our job is that we automate away manual labor, saving time and freeing people to do more manual work. We scrutinize every manual task?our customers or stakeholder perform with a lens of automation. Yet we easily turn this lens away from our own day-to-day work.
One key area that needs this lens is our code reviews. Much of the manual effort we perform can easily be automated. I have listed some here but there are many more you can choose to automate. We are always?going through a mental checklist of things to look for when reviewing code. Let’s make that checklist explicit, handing at least some of it off to software. Then we can focus on the more valuable work.
Learn more how CodeIt.Right can help you automate code reviews and improve the quality of your code.
