List of requirements for Ruby on Rails application code

In my practice, Ruby and Ruby on Rails have proven to be the hardest to learn using a combination of language and framework. Those people who started programming with C, C ++ or Java will find a completely different (and more correct!) Approach to OO design in Ruby, and in Rails there will be many interesting solutions that need to be understood and realized. And although studying Ruby took me a long time (and I’m sure there is still a lot to learn), I love this technology and I’m not going to go back.

I have a fear that as Ruby and Rails grow in popularity, more and more developers will learn about Ruby through the lens of ingrained Java-like thinking. On the one hand it is good. But on the other hand, this is bad because low-quality code, when it becomes publicly available, generates even more low-quality code.


')
Since ThriveSmart (the author’s company sotakone ) takes on more and more programmers (not all of them are Ruby on Rails ninjas), we need to constantly check the quality of the code and the architecture of the projects we are developing to keep them high. Together with my good friend Dan, we made a list of requirements for the code, under which all our developers will subscribe. Although the list is still being updated, you can take a look at the current version.

List of requirements for Ruby on Rails application code

1. The controller action should call only one model method after the initial #find or #new. If there is a need, make the model an additional #new or #update method that you will call in the controller.
2. The controller must pass in the view one or a maximum of two variables.
3. All class names and variables should be clear even to a new developer. Avoid long names and abbreviations.
4. All model samples that are made in the controller more than once must be declared as a named_scope.
5. A view is never called @ model.find *.
6. Application code never duplicates Rails functionality.
7. During development, the code is heavily DRY -ed.
8. All functionality common to two or more models is transferred to a separate library / module. ( this rule is also true for sotakone controllers )
9. All functionality used in two or more applications is placed in a separate gem-plugin ( not necessarily in gem, but in the plugin exactly - sotakone ).
10. The application code does not use STI.
11. Architectural solutions should be the simplest. No need to lay in the application the beginnings of future functionality.
12. The “top” level of the application (controller code) should be covered with tests up and down. The more often the code is used by the end user, the more tests must be for him.
13. The code joins the main branch only if all the tests pass.
14. To prevent the reappearance of bugs, a test is created for each bug fixed.
15. The code of each installed plug-in is previously studied.

I confirm that all this is true for my project.
[Developer Name] [Signature]

Further in the original of the article there is a rather large section with explanations of these points. I began to translate it, but very quickly I got tired of it, since the obvious things are told there. If any of the items on the list seems to be controversial or incomprehensible to you, I suggest discussing it in the comments.