Obie Fernandez: Ruby coding best practices
Posted by Annalisa Afeltra in
Ruby on Rails -
no comments
Through examples e fragments of code Obie show the practices to avoid when developing in Rails.
Obie: You need to know the basis of ruby before you can declare yourself a Rails developer. David Black has published a book for those who would like to learn ruby knowing only Rails.
Those who do not know Ruby can construct a very complicated construction when you could use ‘shortcut’ offered by Ruby; we don’t reinvent things that Ruby has already created and optimized. (for example there exists a function include? to control if an element is in an array without creating a cycle).
It is important to use the routes and the dynamic associations
On the screen appeared a method that before carries out a query on all the photos to choose a random id and retrieve with another query that photo, clearly not a good programming example.
At times the laziness easily takes the programmer to make various errors.
It is important to use various methods that follow simple actions, not to create methods that make many diverse things!
The speaker in front now ironically defines some errors “Premature DeOptimization” that are centered on generating code that decreases the execution of the application, also to generate actions directly in the ApplicationController is not a good idea.
Abuse of the database, happens when we use without too much reflection the functionality of ActiveRecord (like for example we use with light association dynamically inside the cycle).
Also to use the cache in a way that is wrong and dangerous. You don’t cache anymore putting the data inside the global constants/variables in how much it finishes all the RAM.
Don’t create controllers that are too long.
On the screen appeared a long action (about a hundred lines) that at the end of the process has ‘return true’, applauding and laughs came from the room. It is important that you encapsulate all the logic of the business in the models following the thin controller principle, fat models.
We must also be careful to maintain the code created always readable, not to be tempted to “compress” the code too much.
The RESTful architecture must be used correctly (on the screen compiles a controller attached to a shopping site with various procedures, that are for nothing RESTful)
We need to always try to use diverse plugins that make the same thing to understand which is the most functional and performance the best.
When the HTML helper degenerates: on the screen appeared a helper to generate a frame and inside a photo, the helper is hundreds of rows long and the speaker shows how difficult it is to maintain a function of this type. In this case what does it verify, says the speaker, it is good to know that it is needed to generate a new level of extraction to manage the problem (for example to create a ad-hoc model).
We create a methods with constant names, that are most possibly self explanatory (on the screen appears a method that is called finderer that returns a set of options for a method find, difficult to extrapolate without reading the comments).
We cancel the commented code, in any case we use SVN or GIT that keeps track of these things….
On the screen appears the UsersController, an complete application all in a controller, the curse of best practice, applauding and laughs came from the audience.
Conclusions
- learn the fundamentals (of Ruby, of Rails) Rails is not a magic language that makes programmers those who don’t know, it is faster to establish on the conventions but it is necessary to know how to use them!
- learn to learn from people that know more than us, if it is maybe possible to program together with people (pair programming). (the best would, says Obie would be to take SmallTalk programmers with years of experience)
- Read books about the subject.
Annalisa
