Use git history to track how often a file is changed and use it as metric for maintainability

[1000i100]

Like #58 suggest to use coverage as extra scoring metric, i remember static code analysis using change frequency or amount as metric to smell bad architecture design (and so low maintainability).

For example : if we sort every file in the project by commit number where there are involved :

• small commit number on a file is a good smell
• how far a file is from median or average file in commit number can be a bad smell (10x more than average is a very bad smell)

what do you think about this ?

[1000i100]

It was based on CodeClimate reports https://codeclimate.com/github/codeclimate/codeclimate/trends/churn