1 The code review

 

This chapter covers

  • Introducing the code review process
  • Who this book is for (and who it’s not for)
  • How this book is structured
  • What’s in a typical code review?
  • The benefits of a code review
  • Typical pain points
  • How we can make code reviews better

Mike, a developer on a small software development team, just finished a new feature on Friday. He built an entirely new invoice parsing system that would render customers’ invoices as a PDF. And he finished it just in time for his vacation in Cancún. Sure, there were some workarounds and hacks in parts of his code, but hey, it worked. Excited, he quickly merged his new feature into production; not only did he want to go on vacation, but he also wanted to impress his colleagues (Adrienne, Erica, and Justin) by having something deployed while he wasn’t even in the office.

On Monday morning, Adrienne stared at her screen confused. She asked both Erica and Justin if they knew anything about this random new feature – and more importantly, if anyone understood the code that was now part of their codebase. Both defeatedly shook their heads “no.” As they huddled around Adrienne’s screen to try and understand the mystery code, Mike shared photos of his vacation in the team’s messaging channel – beaches he laid on, margaritas he drank, and tasty dishes he ate. The team sighed.

1.1 Who this book is for

1.2 How this book is structured

1.3 What’s in a code review?

1.4 You should want code reviews

1.4.1 Better applications

1.4.2 Happier teams

1.5 Why code reviews (or the lack thereof) can suck

1.6 Convincing your team

1.7 Making code reviews better

1.8 Summary

1.9 References

sitemap