{"id":26709,"date":"2017-06-17T11:03:19","date_gmt":"2017-06-17T11:03:19","guid":{"rendered":"https:\/\/dev.railscarma.com\/rails-development-coding-conventions-best-practices\/"},"modified":"2024-01-10T11:41:26","modified_gmt":"2024-01-10T11:41:26","slug":"mejores-practicas-de-convenciones-de-codificacion-de-desarrollo-de-rieles","status":"publish","type":"post","link":"https:\/\/www.railscarma.com\/es\/blog\/articulos-tecnicos\/mejores-practicas-de-convenciones-de-codificacion-de-desarrollo-de-rieles\/","title":{"rendered":"Desarrollo de Rails: convenciones de codificaci\u00f3n y mejores pr\u00e1cticas"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Lo que hay en un nombre<\/h4>\n

A good name answers important questions. What does it contain? What does it mean? How would I use it?
\nWhat  role  does  it  play?
\nAlways name your methods based on their behaviour, not implementation.
\nConsider,<\/p>\n

\"coding\"<\/a><\/p>\n

By looking at the method name above, we can predict it\u2019s going to perform 2-3 database operations, but
\nwhen I\u2019m working in Business model, why would it concern me?
\nGoing  by,  naming  method  based  on  their  business  role,  the  method  can  be  renamed  as,<\/p>\n

\"Rails<\/a><\/p>\n

Denominaci\u00f3n estructural<\/strong><\/h4>\n

Another common strategy is to name things for their role in the program. It\u2019s the input or the output. It\u2019s the recurring phrase or the middle sentence.  Consider the code for counting differences between two points;<\/code><\/p>\n

\"\"<\/a><\/p>\n

Here the arguments first and second are pretty vague, considering the fact that we\u2019re not even sure if the order matters. In this context, it doesn\u2019t.
\nI can then restructure my code as;<\/p>\n

\"rieles\"<\/a><\/p>\n

Lo que podemos concluir de esto es que el primer paso fue describir el problema en ingl\u00e9s. El c\u00e1lculo de la distancia entre dos cadenas se basa en el recuento de mutaciones encontradas entre las dos cadenas.<\/p>\n

Refactorizaci\u00f3n<\/strong><\/h4>\n

Reorganizar el c\u00f3digo es generalmente bastante trivial. La parte complicada es saber por d\u00f3nde empezar y reconocer que puedes hacerlo. Parte de superar esa barrera es simplemente hacerlo unas cuantas veces. Encuentra un condicional y, para cada uno de sus bloques, crea un objeto cuya \u00fanica responsabilidad sea hacer esa cosa.<\/p>\n

Refactoring is about recognizing a snippet of code as exhibiting characteristics that are known to be problematic.Applying a change that is known to fix this category of problem.
\nThis problematic pattern is called Code Smell, \u201ccode smell is a surface indication that usually corresponds to a deeper problem in the system.\u201d \u2013 Martin Fowler
\nStarting small is never a bad idea, if you can refactor code at micro level, then when it all comes together, it will become a refactored code.
\nConsider two code snippets for example,<\/p>\n

\"sum\"                       <\/a>\"old\"<\/a><\/p>\n

\u00bfCu\u00e1l es la similitud en los fragmentos de c\u00f3digo anteriores? Ambos tienen cada bucle, y si intentamos encontrar su c\u00f3digo huele,<\/span>
<\/p>\n