Replace some trivial Rubocop checks with more meaningful Reek checks.

[fhwang]

Our Ruby static analysis makes extensive use of Rubocop, but in my opinion Reek is a superior analysis tool for Ruby: It offers sophisticated checks that point the way towards better object-oriented design, as opposed to the more superficial analysis style of Rubocop.

This PR is a suggested way to adopt Reek: By taking on some of its checks, and at the same time removing some Rubocop checks that are relatively low value. The goal here is to keep roughly the same amount of static analysis strictness, but refocusing developer effort on deeper analysis of OO design.

As a proof of concept I've run these changes on velocity here: https://codeclimate.com/repos/59f12f7da7c8dc02c00011be/pull/12377

[filipesperandio]

I am up to give it a try!

[filipesperandio]

Guess we should keep the dot to avoid confusion.

Suggested change

	Every project should start with the `reek.yml` present here. It should
	Every project should start with the `.reek.yml` present here. It should

[wfleming]

I think it's referring to the file in this repo, though, not the name it'll get when pulled into a project.

[kurko]

This was my main thought when I saw this PR. What you wrote here hits home for me. I think of reek as valuable, specially for growing teams. It helps drive some level of quality for some standards without too much PR micromanagement.

In some aspects, though, it's like a very purist tool. In some cases we need to make an executive decision to sacrifice something for a benefit somewhere else, and in those moments I found reek to be annoying.

I'm interested in the list of rules you set up, it looks like you gave it some thought and also recognize that it's aggressive so I'm quite interested 😄

[larkinscott]

+1 on giving this a try. Thanks for adding this!

[samdallas]

This looks cool! is it possible to add instructions for running this locally to the readme? I think especially as we get used to it, it would be helpful to be able to check output locally before pushing to a PR.

[wfleming]

@samdallas it's funny you should ask about that, because up until now I think we just assumed everyone would know about running the Quality CLI locally because it was the product we worked on all the time.

You can read instructions for installing the CLI at https://github.com/codeclimate/codeclimate. Once it's installed, you can fetch any shared config files by running codeclimate prepare from within a project, and then codeclimate analyze to run analysis (on the whole project - there are flags available to run specific plugins or only check specific files).

[samdallas]

@wfleming thank you! 🤯 I didn't know that was possible!

[ale7714]

Thank you Francis! We should totally try this changes :)