Summary

In this chapter, we have discussed the importance of performing code reviews and the complete process of getting code ready for review and responding to reviewer comments as the programmer, along with how to lead a code review and what to look for when performing a review as the code reviewer. It can be seen that there are clearly two roles in a peer code review. These are the reviewer and the reviewee. The reviewer is the person performing the code review, and the reviewee is the person whose code is being reviewed.

You have also seen how you, as a reviewer, can categorize your feedback and why soft skills are important when providing feedback to fellow programmers. And as a reviewee whose code is being scrutinized, you have seen how important it is to build upon positive and optional feedback and how important it is to act upon critical feedback.

By now, you should have a good understanding of why it is important to conduct regular code reviews, and why they should be done before the code is passed on to the QA department. Peer code reviews do take time and can be uncomfortable for both the reviewer and reviewee. But in the long run, they work toward a high-quality product that is easy to extend and maintain, and they lead to better code reuse as well.

In the next chapter, we will be looking at how to write clean classes, objects, and data structures. You will see how we can organize our classes, ensure our classes only have one responsibility, and comment on our classes in order to assist with documentation generation. We will then look at cohesion and coupling, designing for change, and the Law of Demeter. Then, we will look at immutable objects and data structures, hiding data, and exposing methods in objects, before finally looking at data structures.