Benefits & Best Practices of Code Review

Photo by Bochelly

Code reviews are methodical assessments of code designed to identify bugs, increase code quality, and help developers learn the source code. Developing a strong code review process, or utilizing version control, sets a foundation for continuous improvement and prevents unstable code from shipping to customers.

Software developers should be encouraged to have their code reviewed as soon as they’ve completed coding to get a second opinion on the solution and implementation. The reviewer can also act as a second step in identifying bugs, logic problems, or uncovered edge cases. Reviewers can be from any team or group as long as they’re a domain expert. If the lines of code cover more than one domain, we should have experts from both domains.

Benefits of Code Review

Knowledge Sharing: 

When software developers review code as soon as a team member makes changes, they can learn new techniques and solutions. Code reviews help junior developers learn from more senior team members, similar to how peer programming effectively helps developers share skills and ideas. By spreading knowledge across the organization, code reviews ensure that no person is a single point of failure. Everyone has the ability to review and offer feedback. Shared knowledge also helps team members take vacation, because everyone on the team has background knowledge on a topic.

Discover Bugs: 

Rather than discovering bugs after a feature has been shipped and scrambling to release a patch, developers can immediately find and fix problems before customers ever see them. Moving the review process earlier in the software development lifecycle through unit tests helps developers work on fixes with fresh knowledge. When waiting until the end of the lifecycle to do a review, developers often struggle to remember code, solutions, and reasoning. Static analysis is a cheap, efficient way to meet business and customer value.

Maintain Compliance: 

Developers have various backgrounds and training that influence their coding styles. If teams want to have a standard coding style, code reviews help everyone adhere to the same standards. This is especially important for open source projects that have multiple individuals contributing code. Peer reviews bring in maintainers to assess the code before pushing changes.

Enhance Security: 

Application security is an integral part in software development, and code reviews help ensure compliance. Security team members can review code for vulnerabilities and alert developers to the threat or even setup the quality gates in static code analysis to make sure they are identified well ahead. If your application is dealing with sensitive information then team should be trained on secure coding practices.

Increase Collaboration: 

When team members work together to create a solution, they feel more ownership of their work and a stronger sense of belonging. Authors and reviewers can work together to find the most effective solutions to meet customer needs. It’s important to strengthen collaboration across the software development lifecycle to prevent information silos and maintain a seamless workflow between teams. To successfully conduct code reviews, it’s important that developers build a code review mindset that has a strong foundation in collaborative development.

Best Practices

What to look for during the code review

It’s important to go into reviews knowing what to look for in a code review. Look for key things like code structure, style, logic. performance, test coverage, code readability and maintainability.

You can do automated checks (e.g., static analysis of the code) for some of the things like structure, style, standards and logic. But others areas like design and functionality, requires a human reviewer to evaluate as we don't have any tools for the same.

Reviewing code with certain questions in mind can help you focus on the right things. For instance, you might evaluate code to answer:

• Do I understand what the code does? 
• Does the code function as per the requirements? 
• Does this code has been written as per the company standards requirements?
  
  

Build and Test — Before Code Review

In today’s time, we have Continuous Integration setup as part of the process. It’s key to build and test before doing a manual review. Ideally, the code review should be done after tests have passed. This ensures stability and doing automated checks first will cut down on errors and save time in the review process.

Limit Review Time for 45-60 Minutes

Never review for longer than 45 - 60 minutes at a time. Performance and attention-to-detail tend to drop off after that point. It’s best to conduct code reviews often (and in short sessions). Taking a break will give your brain a chance to reset. So, you can review it again with fresh eyes.

Review 300 Lines at a Time

If you try to review too many lines of code at once, you’re less likely to find defects. Try to keep each code review session to 300 lines or less. Setting a line-of-code (LOC) limit is important for the same reasons as setting a time limit. It ensures you are at your best when reviewing the code.

Give Feedback that Helps

Try to be constructive in your feedback, rather than critical. Be kind, explain your reasoning, balance giving explicit directions with just pointing out problems and letting the developer decide and encourage developers to simplify code or add code comments instead of just explaining the complexity to you.

Giving feedback in-person for the new members will help you communicate with the right tone as they will be new to the process.

Communicate Goals and Expectations

You should be clear on what are the goals of the review, as well as the expectations from reviewers. Giving your reviewers a checklist will ensure that the reviews are consistent. Engineers will evaluate each other’s code with the same criteria in mind.

By communicating goals and expectations, everyone saves time. Reviewers will know what to look for — and they’ll be able to use their time wisely in the review process.

Include Everyone in the Code Review Process

No matter how senior the engineer is, everyone needs to review and be reviewed. After all, everyone performs better when they know someone else will be looking at their work. When you’re running reviews, it’s best to include engineer and leads/architect. They’ll spot different issues in the code, in relation to both the broader codebase and the overall design of the product.

Including everyone in the review process improves collaboration and relationships between programmers.

Automate to Save Time

There are some things that reviewers will need to check in manual reviews. But there are some things that can be checked automatically using the right tools. Static code analyzers, for instance, find potential issues in code by checking it against coding rules. Running static analyzers over the code minimizes the number of issues that reach the peer review phase. Using tools for lightweight reviews can help, too.

By using automated tools, you can save time in peer review process. This frees up reviewers to focus on the issues that tools can’t find — like usability.

Conclusion

Code review is a critical process in software development that helps ensure the quality, reliability, and maintainability of the codebase. By following these best practices, your code review process can be an effective tool for ensuring that your codebase is high-quality and maintainable, while also promoting a positive and productive development culture.

I would like to thank my wonderful team members who bought the idea of why code review is important and helped me to build automation to save time for everyone. We automated to identify number of lines of code updated in a pull request. If the lines is above X number then it will reject the pull request by adding an appropriate message for the author. 

Thanks to the latest version of sonar which allows us to have a pull request based analysis that considers only the code that are added/updated. Automated the first round of the code review is done by a bot which pulls the data from the static analysis tool and highlights blockers, critical and major technical debts within the new code added.

Read More

Understand Code Refactoring Techniques to Improve your Code Quality

Photo by Danial Igdery

Now a days, agile teams are under tremendous pressure to write code faster with enhanced functionality in short time. There would be some or the other functionality added at the last moment or just before the release. As engineers are under pressure, the functionality gets implemented in a sloppy manner, which may technically work but may lead to dirty code.

Dirty code usually results from a developer’s inexperience, shortcuts taken to meet increasingly tight deadlines, poor management of the project, several different developers working on a project over time, or some combination of all of the above.

Bad code comes at a price, and writing good code isn’t that complicated. Let's understand what's code refactoring.

Code Refactoring

In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes), while preserving its functionality. 

Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object model to improve extensibility. 

Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.

Code refactoring helps to change this dirty code into clean code and it helps to make it easier to extend the code and add new features easily in the future. Also, helps to improve the more objective attributes of code such as code length, code duplication, and coupling and cohesion, all of which correlate with ease of code maintenance and your code will use less memory and perform better and faster.

How to Perform Code Refactoring?

Now that you know the answer to the question of what is code refactoring, and you know many of its potential benefits, how exactly do you refactor code?

There are many approaches and techniques to refactor the code. Let’s discuss some popular ones.

Red-Green Refactor

Red-Green is the most popular and widely used code refactoring technique in the Agile software development process. This technique follows the test-first approach to design and implementation, this lays the foundation for all forms of refactoring.

Red - The first step starts with writing the failing red-test. You stop and check what needs to be developed.

Green - In the second step, you write the simplest enough code and get the development pass green testing.

Refactor - Find ways to improve the code and implement those improvements, without adding new functionality.

Refactoring by Abstraction

This technique is mostly used by developers when there is a need to do a large amount of refactoring. Mainly we use this technique to reduce the redundancy (duplication) in our code. This involves class inheritances, hierarchy, creating new classes and interfaces, extraction, replacing inheritance with the delegation, and vice versa.

Pull-Up Method - It pulls code parts into a superclass and helps in the elimination of code duplication.

Push-Down Method - It takes the code part from a superclass and moves it down into the subclasses.

Refactoring by abstraction allows you to make big changes to large chunks of code gradually. In this way, you can still release the system regularly, even with the change still in progress.

Composing Method

Code that is too long is difficult to understand and difficult to implement. The composing method is a code refactoring approach that helps to streamline code and remove any code duplications. This is done through extraction and inline techniques.

Extraction - We break the code into smaller chunks to find and extract fragmentation. After that, we create separate methods for these chunks, and then it is replaced with a call to this new method. Extraction involves class, interface, and local variables.

Inline - Refactoring also helps to create simpler, more streamlined code. It helps to remove unnecessary methods within the code and replaces them with the content of the method. After that, we delete the method from our program.

Simplifying Methods

As legacy code gets older and older, it tends to become more polluted and complex. In this sense, simplifying methods help to simplify the logic. These methods include adjusting the interaction between different classes, along with adding a new parameter or removing and replacing certain parameters with explicit methods.

Simplifying Conditional Expressions - Conditional statement in programming becomes more logical and complicated over time. You need to simplify the logic in your code to understand the whole program. There are so many ways to refactor the code and simplify the logic. Some of them are: consolidate conditional expression and duplicate conditional fragments, decompose conditional, replace conditional with polymorphism, remove control flag, replace nested conditional with guard clauses, etc.

Simplifying Method Calls - In this approach, we make method calls simpler and easier to understand. We work on the interaction between classes, and we simplify the interfaces for them. Examples are: adding, removing, and introducing new parameters, replacing the parameter with the explicit method and method call, parameterize method, making a separate query from modifier, preserve the whole object, remove setting method, etc.

Extract Method

The extract method is one of the techniques for code refactoring that helps to decrease complexity, while also increasing the overall readability of the code.

When you find that a class has so many responsibilities and too much thing is going on or when you find that a class is unnecessary and doing nothing in an application, you can move the code from this class to another class and remove it completely from the existing class. It involves the moving of a fragment or block of code from its existing method and into a newly created method, which is clearly named in order to explain its function.

Conclusion

Engineers are the only ones responsible for writing good and quality code. We should all make it a habit to write good code from the very beginning. Writing clean code isn’t complicated and doing so will help both you and your colleagues. A clean and well-organized code is always easy to change, easy to understand, and easy to maintain.

Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin

Even bad code can function. Every year, countless hours and significant resources are lost because of poorly written code but it doesn't have to be that way.

Refactoring: Improving the Design of Existing Code by Martin Fowler

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Quick Tips

• Always perform code refactoring in small chunks by making your code slightly better and leaves the application in a working state. Run jUnit tests after making small changes in the refactoring process. Without running these tests, you create a risk of introducing new bugs.

• Do not create any new features or functionality during the refactoring process. You should refactor the code before adding any updates or new features into your existing code.

• Refactoring process always results in complete regression, don't forget to involve your QA team in the process.

Read More