Una revisión de código sin tus lentes

Ésta entrada es una traducción y adaptación de la titulada «Code Review Without Your Glasses», escrita originalmente por Robert Heaton el 20 de Junio de 2014.

---

Imagina que eres parte de un equipo de desarrollo con una sabiduría más allá de lo normal y han destinado un día completo sólo para revisiones de código. Sin embargo, después de las dos primeras horas, te das cuenta que has olvidado tus lentes y has estado viendo fijamente coloridos difuminados toda la mañana. ¿Qué puedes hacer?

La respuesta correcta es ir de regreso a casa y obtener tus lentes, ya que se encuentra a sólo 10 minutos caminando y es un día agradable. Pero asume que, en cuanto dejabas tu casa ésta mañana, descubriste que un enjambre de avispas particularmente aguerridas recién había completado la construcción de un nido en el guardarropa donde guardas tus lentes y no se observaban deseosas de ser molestadas. ¿ENTONCES QUÉ?

Ahora la respuesta correcta es, por supuesto, evitar la pena de pretender que estás usando lentes de contacto y recordar que puedes decir mucho de un archivo sin tener que leer su contenido.

Imagen 1

Podemos acordar que las responsabilidades deben estar absolutamente separadas. Y, por supuesto, cada clase sólo debe ser responsable de hacer una cosa. Pero, éste objeto CreadorDeUsuarios que has construido aquí probablemente está llevando las cosas demasiado lejos. Si esto es todo lo que el CreadorDeUsuarios tiene que hacer, entonces los Usuarios pueden crearse a sí mismos por ahora. De otra forma, lo que era antes un simple Usuario.new innecesariamente se vuelve una infernal pesadilla de  tener que usar grep durante la mitad del camino alrededor del mundo, a través de múltiples pequeños archivos en el momento que quieras cambiar algo o entender que foo está pasando.

Imagen 2

Observando éste largo método disfrazado cómo clase, se ve técnicamente todo muy DRY y no hay nada que pueda ser refactorizado en el sentido literal de la palabra. Pero algo me dice que no usaste pruebas unitarias. Y mientras que, si me das una tarde y algo de café fuerte, puedo trabajar a través de ese bloque de 20 líneas de en medio que es usado para decidir a que usuarios necesitamos enviarles correos, humildemente te sugeriría que metieras en medio un def usuarios_a_enviar_correo para no tener que hacerlo.

Imagen 3

Bien, así que los métodos en ésta clase son mucho más cortos y eso es probablemente un progreso. Sin embargo, haces algo bueno en exceso. Mientras que al intérprete de Ruby no le importan tus continuos saltos entre métodos, pero a la mayoría de los intérpretes humanos le importa. Soy tan feliz cómo cualquiera de deslizarme alrededor del archivo un poco, pero cuando tengo que comenzar a escribir un registro del stack en mi brazo para recordar desde donde llegué, es probablemente tiempo de agrupar y consolidar algunos de esos métodos.

Imagen 4

Veo que estás dispuesto a hacer que ésta clase ocupe exactamente el namespace correcto. Muy bien, crear namespaces es bueno. Pero para el momento en que llegaste al sexto nivel, parece que estás intentando meter mucho en un espacio pequeño. Considera bien dejar de dividir namespaces de forma tan fina (sí, puedo ver que esas dos clases Ayudante podrían tener su propio namespace Ayudante, pero ¿están realmente dañando algo si se colocan en el siguiente nivel arriba?), o desacopla y divide parte del código en un namespace completamente diferente.

Imagen 5

Explicaciones en comentarios, ¡muy bien! Código que requiere se acompañado de un ensayo de varios capítulos, muy mal.

Imagen 6

Observa detenidamente al segundo método hacia abajo. Si el método necesita 8 argumentos para saber que tiene qué hacer y cómo hacerlo, ese método está muy sobrecargado. Distribuye la carga y quita algo del peso de sus hombros con una refactorización temprana. Divídelo en dos (o más), o tal vez tiene más sentido pasar algunos de esos argumentos a la instancia en su inicializador. ¿Podrías tú manejar 8 argumentos de forma simultánea? Entonces no esperes que tus métodos lo hagan.

- o -

Así es el cómo hacer una revisión de código cuando has olvidado tus lentes o has estado mirando fijamente el sol por más tiempo del que los médicos recomiendan. Si fuera mejor programando tal vez hubiera podido ofrecer algunos ejemplos mucho más sutiles. Por otro lado, podría argumentar (y tengo la completa intención de hacerlo) que la trivialidad puede ser interesante aveces. Por más claro, simple y bien formado que pueda ser tu diseño, no sirve de nada si lo construyes con lodo y palillos de madera.