Ruby is a dynamic, expressive and flexible language. To achieve programmer happiness Ruby has a large standard library. And, if you use Rails, the standard library is even bigger. There are many ways to do things with Ruby. This is often what draws programmers to it in the first place.
However, as a project grows in size and complexity, more structure is required in order to manage it. Structure must be added at multiple levels of abstraction: syntax, testing, project structure as well as framework and language usage. Most of these facets can be improved by tooling.
Does the project allow trailing whitespace? Does it use
self.some_method or both for class method definition? Does it allow method params to be defined without parentheses?
In isolation these decisions are trivial, which is why you should set a standard and stick to it throughout the codebase. Inconsistent syntax makes code hard to read and causes pointless arguments in code reviews.
Code coverage tools should be used to maintain high code coverage. Whatever your desired coverage (why not 100%?) you should use a tool to ensure that coverage doesn’t drop. Use something like SimpleCov and add it to CI. If you’re using SimpleCov, I recommend setting the
SimpleCov.refuse_coverage_drop option to prevent PRs from lowering coverage. That way, coverage will increase overtime.
Consistent project structure is very important. For example, if a project uses service objects you don’t want new developers adding logic to the models. Or if you implement the strategy pattern, future developers should continue using the pattern when adding new behaviour. Unfortunately, these things are difficult to enforce automatically. But, there may be tools out there that I haven’t discovered - please tell me if you know any.
The best way to maintain a good and consistent project structure is through pull request reviews and pair programming.
Framework and language usage
Lastly, there are tools like rails_best_practises that give you language and framework suggestions. rails_best_practises won’t improve high level design but it will find law of demeter violations or tell you not to use default scopes. I find rails_best_practises invaluable for writing clean and performant rails code.
Make use of all the great Ruby community tools. Add them into CI so that PRs all follow the same high standards.