Automate Everything: Ruby, Linux and other hints, tips and tricks.

Checklist sobre la calidad de tu proyecto Ruby on Rails

checkboxAparece en RailsInside un interesante artículo que Matthew Paul Moore escribió hace ya un tiempo pero que merece la pena leer. Se trata de una lista de cualidades que debería tener todo proyecto Ruby  on Rails.

Sin entretenerme más paso a enumerarlas en Español. Podéis leer las aclaraciones sobre ellas en el artículo original:

  • Cada acción de los controladores debe llamar a un sólo método del modelo aparte del find o new inicial. Para ello se crearán nuevos métodos new o update cuando sea necesario
  • Vista y Controlador compartirán dos variables de instancia como mucho
  • Los nombres de variables y clases deben ser inmediatamente obvias para programadores nuevos y tan cortas como sea posible sin usar abreviaturas.
  • Todas las llamadas personalizadas a find que se usen en más de un lugar deberán hacer uso de un named_scope en su lugar.
  • Nunca se hará uso de un find o find_by_ desde una View o ViewHelper
  • Hay cero código propio que duplica una funcionalidad ya existente en Rails
  • El código ha sido seriamente DRYed (Don’t Repeat Yourself) durante el desarrollo
  • Toda funcionalidad usada en dos o más modelos ha sido convertida en una librería o módulo
  • Toda lógica duplicada en dos o más aplicaciones ha sido convertida en gema o plugin
  • STI (Single Table Inheritance) no debe usarse nunca
  • Cada elección de diseño debe mostrarse de la forma más simplista posible para cubrir las necesidades del usuario. No se realizarán suposiciones sobre funcionalidades futuras
  • Los test cubren casi toda la aplicación en su nivel más alto. Tienen prioridad las funcionalidades más usadas
  • Todos los tests pasan antes de hacer un merge en un repositorio público
  • Cada defecto arreglado en un proyecto en producción posee tests para prevenir regresiones
  • Se ha revisado el código de cada plugin instalado

Verdades como puños en mi opinión. Y aunque seguro que todos hemos pecado de incumplirlas en alguna vez. Uno no debe dejar nunca de aprender y mejorar.

  • # STI (Single Table Inheritance) no debe usarse nunca

    ¿porqué?

  • La opinión del artículo original es que da más dolores de cabeza de los que ahorra. Añadir columnas en Rails es tan fácil que no merece la pena que dos modelos distintos la compartan. Y compartír lógica se resuelve fácilmente mediante el uso de módulos.

You can follow any responses to this entry through the RSS 2.0 feed.