Add JSON output format option to rails stats command

[euglena1215]

Motivation / Background

The rails stats command is extremely useful for assessing the health and maturity of Rails applications. Currently, the output of this command is primarily in table format, which is suitable for human interpretation but not well-suited for use with automated systems.

In this Pull Request, I propose a feature that allows the rails stats command to output in JSON format, facilitating continuous monitoring of application maturity and health. By supporting JSON output, it becomes easier to analyze statistical data and integrate it with monitoring tools and dashboards. This enhancement will enable developers to visualize changes in the codebase in real time and respond swiftly as needed.

Detail

This change introduces a format option to the rails stats command. When utilized, this option allows for the output to be provided in JSON format, enabling programs and automated systems to directly parse the statistical data.

Example usage:

$ bin/rails stats[json] | jq .
{
  "code_statistics": [
    {
      "name": "Controllers",
      "statistic": {
        "lines": 12345,
        "code_lines": 12345,
        "classes": 123,
        "methods": 1234
      }
    },
    ...
  ],
  "total": {
    "lines": 12345,
    "code_lines": 12345,
    "classes": 123,
    "methods": 1234
  }
}

This change does not affect existing functionalities. The format option is optional, and the default behavior remains unchanged. If the option is not provided, the command will continue to output results in the traditional table format, as before.

Additional information

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one change. Unrelated changes should be opened in separate PRs.
• Commit message has a detailed description of what changed and why. If this PR fixes a related issue include it in the commit message. Ex: [Fix #issue-number]
• Tests are added or updated if you fix a bug or add a feature.
• CHANGELOG files are updated for the changed libraries if there is a behavior change or additional feature. Minor bug fixes and documentation changes should not be included.

[fatkodima]

Can you please provide real-world examples when/where monitoring of this information can be useful? And how this monitoring is expected to be done.

[euglena1215]

@fatkodima
Thank you for your comments. Currently, I am not monitoring my Rails applications, so my observations are hypothetical. However, I believe the features I've proposed could provide valuable insights. Here’s how:

1. Monitoring the trend of code volume in Models, Views, and Controllers:
This can highlight issues like the 'fat controller, skinny model' scenario, where logic overly concentrates in controllers. Ideally, the model's code volume should also increase, reflecting better distribution of logic.

2. Observing the usage of Service classes:
I aim to reduce reliance on Service classes by refocusing on domain-driven definitions within Models, which helps in aligning with domain-driven design principles.

3. Tracking the Code to Test Ratio and Test LOC changes:
These metrics are good indicators of internal quality. Changes in the test code volume, in accordance with the testing pyramid, might suggest improvements in testing practices across different layers.

For monitoring, I plan to automate the collection of these metrics using a daily cron job that pushes logs to a logging platform. Specifically, I intend to send logs to BigQuery and use LookerStudio for visualization of daily changes in the codebase.