To keep the power of Rails under control teams should develop a set of high—level constraints to follow.

I thought that some companies might have been published something like this.

Surprisingly, I found only a few if them: * https://github.com/airbnb/ruby#rails * https://github.com/thoughtbot/guides/tree/master/style/rails * https://docs.gitlab.com/ee/development/README.html#best-practices * https://github.com/hopsoft/rails_standards * http://guidelines.plataformatec.com.br/rails.html

Although, the most of them are about aesthetics, naming conventions and code formatting, and a very little about Rails.

The most interesting one is from GitLab. They explain why they don’t use STI and polymorphic associations, for example.

Yet, it doesn’t give the full picture. I’d like to get these questions answered, for example: * What kind of stuff is ok to put in models? * What gems are fine to use and which ones should be avoided? And why? * What do we do when there is a really complex business logic? Where should it go? * In which situations it is fine to use concerns?

Yet I couldn’t find a single guide answering these and similar questions in public.

Possible explanations:

1. Companies don't have Rails style guides because they have their code. You join a company, you learn conventions from the existing code. 2. Companies treat this knowledge as Know-How and do not want to share it in public. 3. They are not very proud of what they have to share it in public, because of potential criticism. 4. “We’re not sure why we do it in a way we do it”, so we can’t really verbalize the rules.

What do you think on the topic?