Temporal coupling metric

[akash-manna-sky]

Temporal coupling metric

References:
"Your Code as a Crime Scene" (By Adam Tornhill) (page 72).

Fixes #1156

[akash-manna-sky]

References:
"Your Code as a Crime Scene" (By Adam Tornhill) (page 72).

[uhafner]

This looks already promising. How would that interact with the existing forensics code and UI? Can't we combine the other forensics code with your code (backend)? Maybe we can add one column for the percentage? Do you have another idea? We can also provide the data as a separate page if this is more appropriate...

[akash-manna-sky]

Here comes little difficult part for me, though I am trying. The cleanest solution is:

Wire TemporalCouplingMiner into GitRepositoryMiner. Since it already processes CommitDiffItem lists, so temporal coupling can be computed in the same pass with zero extra Git I/O. Store the List<TemporalCoupling> in a new serializable container (e.g. TemporalCouplingStatistics) that gets saved alongside the build via a new BuildAction.

Then, a dedicated separate page makes the most sense because temporal coupling is pair-based, not file-based. Squeezing it into one column of the existing table would be a poor UX — the table is already wide and a pairwise metric belongs in its own view. The separate page would have a table with columns: Left File | Right File | Co-Changes | Coupling %.

Is this enough? Let me know if you have any additional suggestions.

[uhafner]

Wire TemporalCouplingMiner into GitRepositoryMiner. Since it already processes CommitDiffItem lists, so temporal coupling can be computed in the same pass with zero extra Git I/O. Store the List<TemporalCoupling> in a new serializable container (e.g. TemporalCouplingStatistics) that gets saved alongside the build via a new BuildAction.

Can't we integrate the list into the existing class RepositoryStatistics? Then the number of changes can be minimized? Though I haven't looked into the code in detail yet...

Then, a dedicated separate page makes the most sense because temporal coupling is pair-based, not file-based. Squeezing it into one column of the existing table would be a poor UX — the table is already wide and a pairwise metric belongs in its own view. The separate page would have a table with columns: Left File | Right File | Co-Changes | Coupling %.

A new view would be much better, but costs some more effort. I think it is worth to create it. One additional column in the existing view that shows the max. coupling of a class in % (with a given threshold?) would not hurt as additional columns are only shown when there is place in the screen. Maybe this cell can then link to the new coupling view.

[akash-manna-sky]

But the problem is RepositoryStatistics is in forensics-api-plugin, which is a separate repository from git-forensics-plugin. How to integrate this? Please help me how handle this cross repository problem.