When we started developing CodeScene, our overall goal was to show that there is more to code than code; we wanted to highlight–and make actionable–all the information that is invisible in the code itself.
One such prominent piece of information is the social dimension of code, like inter-team coordination needs, on- and off-boarding information, and much more. Today, the social analyses pioneered by CodeScene are one of our most powerful features.
All of CodeScene’s social metrics are based on the author information as recorded by Git. Because Git only recognizes one author per commit, this may not reflect the social reality of your code if your organization does pair or mob programming where more than one person contributes to a single change. Thus, we have worked hard to also cover those scenarios. Let’s see how it works
Configure for Pair Programming
A typical pair programming setup involves committing code from a Git account shared between all team members, and then specifying the actual authors in the commit messages. The next figure shows an example:
Pair and mob programming annotations in the commit messages.
So in case your organization uses pair or mob programming practices, and you have some annotations in your commit messages, you just need to tell CodeScene about it. This is a straightforward configuration of the specific pattern you use. CodeScene will then extract the author information from your commit messages and adjust the knowledge maps by splitting the code contributions between the actual contributors.
Finally, it’s worth pointing out that the author aliases typically used in the commit messages can be resolved by CodeScene too. For example, you might find that most contributors just specify their initials in the commit messages, perhaps as [AT|JF]. If that’s the case, you can use CodeScene’s Developer Identity Mapping to declare AT and JF as aliases of the corresponding developers. Here’s an example:
Modify the name of any author to resolve aliases.
With that configuration in place, you’re ready to explore the knowledge maps over your codebase, pair programmed or not.
Example on a knowledge map that lets you explore the main contributors to each module.
Try it Yourself
The pair programming support is available in our on-premise version, and we’ll add it to the Cloud Version soon too.
