From the course: Agile Software Development: Code Quality

What are hotspots and churn? - SonarQube Tutorial

From the course: Agile Software Development: Code Quality

Start my 1-month free trial

What are hotspots and churn?

“

- [Instructor] So your team has decided to make a commitment to improving code quality. Great, now what should you focus on? Pondering this question can get overwhelming really quick, especially on a pretty large project. Lucky for you, your source code repository, Git as an example, is hiding a treasure trove of information that you can tap into to figure out where to get started. It's easy to think of your source control system as just a system that lets you collaborate with your colleagues or just a tool that helps you quickly roll back a change that caused a bug in production. But that's not quite the full picture. Every time a significant change is made to a file, those changes are checked into your source control repository. You can use the information in the source control history to figure out which files are changing the most. The files that have changed most recently are the ones that your team is focusing on. Quality in those files becomes more important than the files that were last touched a couple of years ago. Churn is simply a count of the number of times a file has changed. You can measure it across the lifetime of your project or you can focus on the more recent changes. Hotspots are files that have higher than average complexity and have changed recently, so basically, the files that generate a lot of churn. There's also more information you can learn from the source control history. Here's a taste. How many different authors contributed to a particular file? Which files were primarily authored by people who are no longer on your team? Does your team follow test-driven development or TDD? It's a design technique where you write your test code before you write the code that makes your test pass. If your team is following it, then the files that comprise your automated tests should be changing just as often as the files that they are testing. One final thing that you can learn from your source control history is which files almost always change at the same time. A tool called CodeScene builds on the open-source project, Code Maat, which was built to support the books Your Code as a Crime Scene and Software Design X-Rays, which are both by Adam Tornhill. Let's take a look at how we can use that next.

Contents