Identifying Potential Code Hotspots
Problem to solve
Code hotspots are important to identify and visualize due to the usually high correlation between code stability and code quality. As a result managers want to understand where their hotspots are at a certain point in time and potentially use these in order to prioritize technical debt. It might be the case that a single module has too many responsibilities and refactoring it into multiple ones with separate ones can stabilize that segment of the code and lead to less quality issues. While there will be false positives in what we consider an MVC for code analytics, by adding further analytics, we hope to help the management of complex interaction between modules and engineers.
Intended users
EM, PM when overseeing refactoring, Senior Tech Executives
Further details
Proposal
- Let's create a treemap where the size of each square is the LOC added/removed during the period (or folder > project > group): https://ecomfe.github.io/echarts-examples/public/editor.html?c=treemap-visual.
- The color of the squares should range from green to red and corresponds to areas, which we believe are hotspots, where the more we believe an area is code hotspot, the more
red
the file becomes. - We should have a dropdown to calculate this for a period of time we select by: 1) average time between commits to a file (the lower the time, more of a code hotspot) 2) the number of commits that touch upon that file (the higher, the more of a code hotspot) (the aggregation is: average number of commits per file). ** We are doing only 2) for the first iteration
- The treemap should know our hierarchy, i.e. group > project/subgroup & project > folders > files, so that every time you click on a rectangle, it creates a new treemap, with the data inside it zoomed (basically trying to get something similar to http://bl.ocks.org/ganeshv/6a8e9ada3ab7f2d88022). We should be able to see the following information as a tooltip or within the rectangle: LOC changed, N of commits, average time between commits (latter not required for first iteration). @aakriti.gupta, you can check https://github.com/adamtornhill/MetricsTreeMap for inspiration.
- The filter from https://gitlab.com/gitlab-org/gitlab-ee/issues/12104 should apply but we can downsize the issue depending on identifying any complexities to potentially start with the files in 1 project without any filtering. First iteration will be 1 project
Permissions and Security
Inline with the rest of the analytics pages now, this feature will be available for Premium users only.
Users should only see groups/projects/subgroups that they have a reporter access to and above.
For gitlab.com, we will only show the groups, projects, subgroups that fall under namespaces of silver (aka premium) and above.
Documentation
Testing
What does success look like, and how can we measure that?
We will want to see weekly engagement with the page.
What is the type of buyer?
Director, but would be beneficial at every layer.
Links / references
Solution
Let's create a tree chart with 4 shades of green, one orange and one red:
This is how the progression of drilling down would work, but the first iteration should only be project level, I.e. the last screenshot.
We can show 2 levels of data: the top levels are separated by an 8px white border, the second level boxes by a 4px border.
The user sets the timeframe on the top left, so let's explicitly state what date range we're showing data for:
As the user drills down, we add the levels to the "breadcrumbs" so that they have an overview of where they are and so that they can navigate back to previous levels by clicking on them:
When the user hovers over the box we show the popover:
Let's "wrap" the chart on mobile screens to keep the charts usable: