Read “Software Design X-Rays”, measure code quality

This month, I read Software Design X-Rays and leave summary and my memos here.

The book shows us how to measure one of code quality and find hotspots, and how to fix or improve them. We also can learn some helpful git script to measure them quickly and get an opportunity to consider how to find/what kind of code is/will be hotspots.

We know some situations will be hotspot like:

• Files/Classes/Methods which have a large number of lines
• Files/Classes/Methods which have complicated logic
• Files/Classes/Methods which change frequently
• Files/Classes/Methods which are modified by many developers
• Project structure is complicated

In this book, we can see them and suggestions how to improve them and real data from OSS projects. It was so interested in large-scale systems related talk.

Human memory is fragile and cognitive biases are real

The significant thing when we consider this kind of topic, we should mention what is technical debt. Technical dept depends on several situations. e.g. Business phase.

So, this book also mentions such thing and sometimes address the organisation itself. We must keep in mind what/when/which is suitable for our world.

Visualise codebase

The book tries to visualise codebase. The author develops and serves https://codescene.io/ to measure and visualise codebase.
We can see examples from the site for some OSS projects such as .NET and Ruby on Rails. Hotspots have a large circle and red colour…

The next figure shows the Ebbinghaus forgetting curve where we quickly forget information learned at day one.

In measuring some metrics, indentation based complexity metrics was the most impressed thing. I also considered such thing and can agree with the way as simple measurement.

Not only coding

One of the interesting thing about this book is this book also mention about organisation and development process.

The data shows us no process, and complicated organisation structure leads hotspots. So, this book also tries to measure team oriented measurement and mapping codebase and organisation/team structure. In the mapping, the author considers boundaries in codebase and organisation base.

A common fifteen-minute coffee break is the cheapest team building exercise you ever get, and we shouldn’t underestimate the value of informal communication channels that help us notice new opportunities and work well together.

Detect Hotspot

• How frequent each file changes

git  log --format=format: --name-only | egrep -v '^$' | sort | uniq -c | sort -r
git log --format=format: --name-only --after=2016-01-01 -- drivers/gpu/ | sort | uniq -c | sort -r

• To show who commits and how many commits they are

git rev-list --count HEAD

• Get authors

git shortlog -s -- .
git shortlog -s --after=2016-09-19 -- . | wc -l

• Get the age of code

git log -1 --format="%ad" --date=short -- particular/file.path

Conclution

The book is in beta yet. But it’s worth for Test/Quality related engineers and some managers and developers as well.

Recently, we can see frequently autonomous team and team autonomy related topics. I read “Designing Autonomous Teams and Services”を読んだ before.
Recent Agile, Microservices and other things step toward to autonomous thing. Personally, the way is the lovely thing.