Over the years, Ruby on Rails (“Rails”) has grown to one of the most favored open source frameworks, based on Ruby programming language; the framework is all know to create server-side web applications. It is the most used MVC framework, and developers find it very easy to understand and use. At the same time, it becomes tough to handle for some developers due to using the wrong approach while handling it. I have been working on the Rails framework for a long time, and I know the most common mistakes which knowingly or unknowingly happen.
A mistake does happen at the time of writing code, or during handling, though if you commit any error unknowingly, it will not let you get into the application flow; as a result, it will affect your productivity. Therefore, I have covered all the vulnerable Rails mistake which you can easily catch and eliminate it, to be into the flow.
A controller having too much Logic
Rails follow a principal "fat model, skinny controller" and every developer is supposed to support it. However, this often found being violated by most developers. Moving view or domain/model Logic to Controller is quite easy, and that is where the problem begins. It makes future changes to the code complicated while keeping your application vulnerable. Here's the type of logic you should have in the controller are;
- Session and Cookie Handling
- Model Selection
- Request Parameter
- Rendering
These are the logics which you require to have in controller.
View having too much Logic
Rails templating engine, ERB, helps to pages with variable, though if you are not attentive, you would probably end up with a large file, having indefensible HTML and Ruby code in the disposal. At the same time, you may also have lots of repetitive code, and that is a direct violation of the DRY principle. You can do away with such issues by following the methods here;
- You can use 'view layouts and partials' to guard their states which are repeated on the pages.
- Presenters/decorators such as Draper gem to do away with view-building Logic.
- The method can be added to the Ruby object and made to perform logical operations.
Model having too much Logic
'Rails' is based on MVC architecture and is known to all. We have discussed the consequences of having too much Logic in Controller and View now will examine the Model. Do not think of putting all the Logic in the model 'ActiveRecord model classes' as it will not only result in violating the single responsibility principle but also make maintenance challenging to handle. So, where will these logics will be then? That's a valid point. You have plain old Ruby objects (POROs), and new developers love to create classes outside of the framework. Having POROs at the place, you can encapsulate things and API interaction into the self-made classes to avoid putting too much load to 'model.'
However, the 'model' should have only the following Logic;
- ActiveRecord configuration
- Simple mutation methods (for updating and saving the attributes to the database)
- Access Wrappers
- Sophisticated Queries
Do You Use Classes as Dumping Ground
Generally, developers, in many cases, create too many classes, and most of them don't fit the model, view, and controller into the helper classes. Being MVC architecture, Rails offers the privilege to developers to create their classes and hold the code for those classes. In Rails, as it being MVC-centric, nothing prevents you from creating your own classes for the new resources designed.
Too Many Gems
Gems are good, but using too many may be the reasons for the app being sluggish. Gems are meant to provide developers capability to make Ruby on Rails development projects highly resourceful, efficient, and effective. You get an easy hand to develop complex applications quickly. However, it is often found that gems used in the app's 'Gemfile' are comparatively large against the functionality integrated using it. Putting a lot of and unnecessary gems may make the file larger and heavily impact on performance and consuming lots of server memory. Besides, it will cost you heavily to maintain this.
One gem comes with dependency on other gems, and that other gem has dependencies on the yet other gems that way it will go on. For example, the 'rails_admin' gem comes up with another 11 gems which cause in 10% incensement in the size of the project.
Why Ignore Your Log Files?
Rails generally have log files available which are ignored by Ruby on Rails developers. The fact of the matter is that most applications rely on Honeybadger or New Relic, the log monitoring tools which needs to follow continuously throughout the development and testing.
Automated Testing
Ruby and Rails are laden with a loaf of automated testing tools, such as TDD and BDD styles. Still, you can find plenty of applications, having no test written. There should be some automated testing in the application.
Conclusion
I have talked may developers, and they know the consequeces of commiting these common mistakes, but they tend to commit. For example, while writing this article, I just asked a very senior developer about the Logic in MVC. He said that Logic has to be in controller, model, and view. I asked, "what types of logic should be there in each of them?" He just said as many as required. I again asked, "Don't you think putting too much logic will impact project?" His reply was interesting as he said, "Yes if you much logic in controller, view or model, it definitely impacts. There will larger project file size, and it will consume lots of server space.
Do I need to explain more? Now, every developer needs to consider this very carefully and keep these small and common vulnerable mistakes in mind while developing your project.
