Desarrollo de Rails: convenciones de codificación y mejores prácticas

Lo que hay en un nombre

A good name answers important questions. What does it contain? What does it mean? How would I use it?
What  role  does  it  play?
Always name your methods based on their behaviour, not implementation.
Consider,

By looking at the method name above, we can predict it’s going to perform 2-3 database operations, but
when I’m working in Business model, why would it concern me?
Going  by,  naming  method  based  on  their  business  role,  the  method  can  be  renamed  as,

Denominación estructural

Another common strategy is to name things for their role in the program. It’s the input or the output. It’s the recurring phrase or the middle sentence.  Consider the code for counting differences between two points;

Here the arguments first and second are pretty vague, considering the fact that we’re not even sure if the order matters. In this context, it doesn’t.
I can then restructure my code as;

Lo que podemos concluir de esto es que el primer paso fue describir el problema en inglés. El cálculo de la distancia entre dos cadenas se basa en el recuento de mutaciones encontradas entre las dos cadenas.

Refactorización

Reorganizar el código es generalmente bastante trivial. La parte complicada es saber por dónde 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 única responsabilidad sea hacer esa cosa.

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.
This problematic pattern is called Code Smell, “code smell is a surface indication that usually corresponds to a deeper problem in the system.” – Martin Fowler
Starting 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.
Consider two code snippets for example,

¿Cuál es la similitud en los fragmentos de código anteriores? Ambos tienen cada bucle, y si intentamos encontrar su código huele,

• Un bucle con una variable temporal.
• Un bucle con un condicional anidado.

Intentemos refactorizarlos.

El primer bucle solo tiene una variable temporal, que se puede arreglar usando 'inject'

Este tiene dos variables temporales y un bucle anidado, ya que estamos tratando de clasificarlas, sort_by debería funcionar. El código se puede refactorizar aún más, ya que estamos tratando de encontrar el valor máximo, podemos usar directamente la función max_by aquí.

Prácticas Generales

• What if we devise a set of rules to follow while coding, that later on reduces our efforts in refactoring.
  The most basic and important point is FORMATTING. It sounds like the most obvious and easy thing to do but it’s very important to format your code correctly. In terms of code readability, understanding for future references, and also while resolving conflicts that occur while merging two different branches.
• Al escribir una condición if con múltiples subcondiciones, intente siempre ordenarlas de manera que requiera el menor esfuerzo. Por ejemplo,

• Si tiene una gran cantidad de lógica que girará en torno a una única funcionalidad, intente dividirla en varios métodos más pequeños. Aumenta la reutilización y además facilita que un nuevo desarrollador comprenda el código fácilmente. En lugar de escribir todo en un solo método y darle la apariencia de una lógica compleja, divídalo en fragmentos de métodos más pequeños y legibles.
• Comenta tu código mágico. Ruby proporciona muchos métodos de metaprogramación que ayudan a reducir el esfuerzo y ahorran tiempo. Pero no siempre son tan fáciles de entender cuando quieres consultarlos, siempre es una buena idea agregar comentarios apropiados para que cuando vuelvas más tarde a echarles un vistazo, te resulte más fácil volver a conectarte.
• Utilice before_filter, en lugar de repetirse en el controlador.
• Utilice devoluciones de llamadas de modelos para evitar escribir demasiado código en los controladores para las acciones que giran en torno a las operaciones CRUD básicas.
• FORMATING: there are certain gems which makes your life much easier : awesome_print ; pretty print ;  rubocop.
• Siga siempre la práctica de revisión de código en Git. El código escrito por un desarrollador debe ser revisado por otros miembros del equipo antes de fusionarlo con las ramas principales, ya que eso ayuda a eliminar posibles errores o resultados inesperados. También ayuda a mantener a todos los miembros informados y actualizados sobre en qué está trabajando su colega.
• Las declaraciones que extienden la publicación a 80 caracteres deben dividirse en las siguientes líneas para evitar la barra de desplazamiento al ver el código en otros medios como GitHub.
• Al enviar código a su repositorio, git diff me dice lo que hizo, su mensaje de confirmación debe decir por qué lo hizo.
• NO OPTIMIZAR para el rendimiento – OPTIMIZAR PARA LA CLARIDAD DEL CÓDIGO
• Las pruebas unitarias siempre son una buena idea para garantizar que la funcionalidad funcione como esperaba. Ayuda por aspecto: Rails genera de forma predeterminada un asistente para cada controlador. Elimínelos e intente utilizar ayudas que estén orientadas a aspectos como; -> link_helper      –> menú_ayudante
• Según la convención de MVC, se debe evitar realizar llamadas a la base de datos desde la capa de Vista. Mueva esa parte de su código a los controladores para garantizar la separación de preocupaciones.
• Reducir las llamadas a bases de datos. Si una página visitada con frecuencia genera más de un par de llamadas a la base de datos, vale la pena dedicar un poco de tiempo para reducir la cantidad de llamadas a solo unas pocas. En muchos casos, esto es sólo cuestión de usar .includes() o .joins().
• Se convierte en una tarea tediosa verificar la estructura de su modelo de vez en cuando; como recurso, incluya la estructura de su modelo en la parte superior del archivo como referencia.

¡Espero que haya ayudado! Cerrando la sesión, Niyanta

Ahorrar

Ahorrar

Ahorrar

Ahorrar

Ahorrar

Ahorrar