Volver a Entradas

revisiones de código sin usar tus lentes

Colocado en Traducciones

Nota: É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.

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É?

La nueva 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.

Clases innecesarias

Fragmento de código ofuscado 1: clases innecesarias

Todos 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 si mismos por ahora. De otra forma, lo que era antes un simple Usuario.new innecesariamente se vuelve una infernal pesadilla de usar grep a mitad de camino alrededor del mundo a través de múltiples pequeños archivos en cualquier momento que quieras cambiar algo o entender que foo está pasando.

Métodos excesivamente largos

Fragmento de código ofuscado 2: métodos excesivamente largos

Observando éste mas bien largo método disfrazado cómo clase, puedo observar que técnicamente es todo muy DRY y no hay nada que pueda ser refactorizado en el sentido literal de la palabra. Pero algo me dice que no usas 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_quienes_enviar_correo para no tener que hacerlo.

Muchos métodos con pocas instrucciones

Fragmento de código ofuscado 3: muchos métodos con pocas instrucciones

Bien, así que los métodos en ésta clase son mucho más cortos y eso es un progreso. Sin embargo, haces algo bueno en exceso. Mientras que al interprete de Ruby no le importan tus continuos saltos entre métodos, a la mayoría de los interpretes 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.

Excesivo uso de namespaces

Fragmento de código ofuscado 4: excesivo uso de namespaces

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 probable que estés intentando meter mucho en un espacio pequeño. Considera bien dejar de dividir namespaces tan finamente (sí, puedo ver que esas dos clases Ayudante podrían tener su propio namespace Ayudante, pero ¿están realmente dañando algo en el siguiente nivel arriba?), o desacopla y divide algo del código en un namespace completamente diferente.

Comentarios excesivamente detallados

Fragmento de código ofuscado 5: comentarios excesivamente detallados

Comentarios con explicaciones, ¡muy bien! Código que requiere se acompañado de un ensayo de varios capítulos, muy mal…

Métodos con demasiados argumentos

Fragmento de código ofuscado 6: métodos con demasiados argumentos

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 simultanea? Entonces no esperes que tus métodos lo hagan.

Así es como 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 ofreces 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, es todo para nada si lo construyes con lodo y uñas de los pies.

David O' Rojo —Ciudadano del mundo, recorriendo el largo camino a la maestría en Desarrollo de Software. Interesado en lenguajes dinámicos, herramientas para el desarrollo web y proyectos enfocados al beneficio de la sociedad.

A Continuación

buenas practicas para revisiones de código