Posted on

9 Best Practices for Effective Code Review

The code writing process requires great mental effort and concentration, which makes it very difficult to achieve a flawless result. However, it’s important to remember there is no such thing as perfect code — programmers should strive to achieve "better" code that constantly can be improved. Reviewing the code author’s work can’t guarantee the prevention of all bugs, but it can protect users from experiencing it. That’s why integrating the code review into the development process helps to deliver high-quality applications that companies expect to get while outsourcing their software development.

Code review is a systematic examination of software source code used to detect mistakes, spot early bugs, track possible defects, and improve general code quality and consistency — this process helps code remain more maintainable. Conducted by fellow programmers and quality assurance specialists, code review aims to accelerate and streamline the software development process. The clean, well-designed, and easy-to-maintain codebase is the foundation for any high-quality, secure, and reliable application.

Posted on

Why Code Reviews Should Be Your Favorite Activity

The code review process is an essential key to maintaining and improving product quality. But it can also be a bottleneck, an unnerving activity for your development team, and may reduce your development productivity. Therefore, you should care about the best practices of the code review process outlined in this article.

Why Should You Care About Code Reviews? 

Most development teams already know the importance of code review activity as practitioners. This section tells C-Levels, Product Managers, and Engineering Managers that investing in code review rewards you with better products and better development teams.

Posted on

How to Make Your Reviewer Cry Using Java Optional

I think code review is one of the best sources of inspiration. I see it as an opportunity to learn new things from other software developers sending pull/merge requests. Moreover, sometimes you may need to study a specific subject with more details regarding the under review code. Usually, this process leads to a more profound knowledge of that domain. However, there’s still another fact about code review: after a while, you face some common mistakes. Recently, I reviewed a feature in which I saw an Optional pitfall. Honestly, I had seen that issue several times in different merge requests sent by several developers (from beginners to experienced ones).

I know that there are tonnes of articles regarding Java Optional, some of which are quite useful like this one (although I have arguments against some of the cases mentioned in the article) by Anghel Leonard, the author of Java Coding Problems. I don’t want to repeat all of the contents you can simply find by googling. I intend to talk about some of the most common and least addressed pitfalls regarding Optional usage.

Posted on

Peer Review vs. Code Review

I used to internally cringe when people mentioned code review – where developers check each other’s work after it has been implemented and suggest improvements. The tests were in place, QA had signed off, the product owner was happy. Surely by definition code review was just the practice of looking for problems.

If that sums up how you feel about code review, then sorry — you’re going to hate this. Nowadays, I think peer review is one of the most powerful devices for projecting best practice in a product, a team, a company and beyond. Notice I call it peer review rather than code review. To me, there are some important differences. Code review is good – it raises standards and awareness of standards. But peer review is more powerful still.