amclin / devopsculture Goto Github PK

The calculations of Code Refactoring Ratio needs to be revised because it is non-continugous:

1. A ratio of undefined would be considered good ( code changes divided by 0 test changes)
2. A ratio of < 1 would be considered bad (more test changes than code changes), and the close to 0 that it gets, the worse it is
3. Ratios above 1.0 increase positively as the value increases

https://github.com/amclin/devopsculture/blob/master/_kpis/code-refactoring.md#todo-future-refinement

With these definitions, a Refactoring Ratio of undefined is ideal (lots of code changes, with no test changes). But a fractional Refactoring Ratio value between 0 and 1 is bad as it indicates code changes require significantly more testing.

Code Refactoring scores will look bad if a release or a file adds unit tests to cover existing code. In effect, this is technical debt (uncovered code) being paid down, but it will cause a good thing to show up as a detrimental indications on the metric.

A significant increase of code coverage without accompanying code changes will reflect as a dropoff when monitoring Code Refactoring Maturity.

Need to figure out a way to refine Refactoring Ratio Maturity in order to eliminate this noise factor. One way to do this is procedural: ignore any releases that are only increases in unit tests. They could be identified by having Refactoring Ratio values of 0 (0 code changes, divided by a defined number)

https://github.com/amclin/devopsculture/blob/master/_kpis/code-refactoring.md#todo-future-refinement