Cuestionario: Principios de Clean Code y Refactorización

Pregunta 1 de 20

¿Qué postura defiende Clean Code respecto a los comentarios en el código?

Debe haber un comentario por cada línea de código

Los comentarios son la única forma válida de documentación de software

El código debe ser auto-explicativo; los comentarios son a menudo un síntoma de código poco claro y tienden a desactualizarse

Solo deben usarse comentarios en inglés, no importa el idioma del equipo

Pregunta 2 de 20

¿Cuál de estos es el concepto fundamental detrás de KISS (Keep It Simple, Stupid)?

Abreviar todas las palabras clave del lenguaje

Insultar a los miembros del equipo que escriben código malo

Evitar la complejidad innecesaria y no sobreingeniar soluciones para problemas que aún no existen

El código debe compilar en un solo archivo plano

Pregunta 3 de 20

¿Qué técnica de refactorización soluciona una función excesivamente larga?

Extract Method (Extraer Método / Función)

Inline Variable (Integrar Variable)

Delete File (Eliminar Archivo)

Rename Variable (Renombrar Variable)

Pregunta 4 de 20

¿Qué significa DRY (Don't Repeat Yourself)?

Evitar el uso de bucles for, prefiriendo map o forEach

Evitar la duplicación de código y lógica centralizando el comportamiento común

No repetir el mismo commit message en Git

No escribir tests redundantes

Pregunta 5 de 20

Según los principios de Clean Code, ¿cómo deberían ser los nombres de las variables?

Deberían incluir siempre el tipo de dato en el nombre (ej. strNombre)

Intencionales y descriptivos, explicando qué contiene o qué hace sin necesidad de comentarios

Aleatorios, ya que el compilador se encarga de entenderlos

Lo más cortos posibles (una letra o dos) para ahorrar espacio

Pregunta 6 de 20

Según Robert C. Martin (Uncle Bob), ¿cuál es la regla de oro sobre el tamaño de las funciones?

Deberían caber en un monitor panorámico

El tamaño no importa siempre que tengan buenos comentarios

Las funciones deben ser pequeñas. Y deberían ser aún más pequeñas.

Deben tener al menos 50 líneas para justificar su creación

Pregunta 7 de 20

¿Qué es un "Code Smell" (Olor de código)?

Un comentario mal escrito o engañoso

Código que utiliza dependencias desactualizadas

Un síntoma superficial en el código que indica un problema más profundo de diseño o estructura

Un error de sintaxis que impide la compilación

Pregunta 8 de 20

¿Qué es un "Magic Number" (Número Mágico) en programación?

El número máximo de conexiones a la base de datos permitidas

Un valor numérico insertado directamente en el código sin una constante que explique su significado

Un número generado algorítmicamente y de forma aleatoria

Un identificador único en bases de datos relacionales

Pregunta 9 de 20

¿Cuál de los siguientes es un Code Smell conocido como "God Object" o "God Class"?

Una clase que no tiene métodos, solo atributos

Una clase abstracta de la que heredan todas las demás

Una clase que interactúa con la base de datos

Una clase enorme que centraliza demasiadas responsabilidades y conoce gran parte del sistema

Pregunta 10 de 20

¿Qué son los "Side Effects" (Efectos Secundarios) en una función y por qué deberíamos minimizarlos?

Efectos visuales CSS lentos en la interfaz

Errores que solo ocurren los fines de semana

Cuando una función modifica un estado externo ocultamente (ej. variables globales, BD) lo que hace el comportamiento impredecible

Los beneficios de utilizar frameworks externos

Pregunta 11 de 20

Según Clean Code, ¿cómo deberías ordenar los métodos dentro de una clase?

Aleatoriamente, lo importante es que compile

Primero los más largos, luego los más cortos

Alfabéticamente para encontrarlos más rápido

De forma descendente como un periódico: función principal arriba, seguida de las funciones secundarias o privadas que invoca

Pregunta 12 de 20

¿Qué es el "Principio Abierto/Cerrado" (Open/Closed - la "O" de SOLID)?

Las entidades (clases, módulos) deben estar abiertas para la extensión pero cerradas para la modificación

Los puertos del servidor deben estar cerrados por defecto y abrirse solo a petición

Las bases de datos deben estar abiertas de día y cerradas de noche

El código fuente debe ser open source y cerrado a empresas

Pregunta 13 de 20

¿Cuál de las siguientes firmas de función es considerada más limpia?

crearUsuario_1_al_6(...)

Ambas son igualmente limpias

crearUsuario(nombre, apellido, email, telefono, direccion, edad)

crearUsuario(datosUsuario)

Pregunta 14 de 20

¿Qué significa el principio "Single Responsibility" (Responsabilidad Única - la "S" de SOLID)?

Todo el proyecto debe tener un único repositorio principal

Cada desarrollador es responsable únicamente de su propio código

Solo un usuario puede acceder a la base de datos al mismo tiempo

Una clase o módulo debe tener una, y solo una, razón para cambiar (hacer una sola cosa)

Pregunta 15 de 20

¿Qué es "Code Duplication" y por qué es peligroso?

Tener dos monitores mostrando el mismo código

Tener backups del código

Copiar y pegar código, lo que causa pesadillas de mantenimiento si la lógica subyacente cambia y se olvida un sitio

Usar control de versiones como Git

Pregunta 16 de 20

Antes de refactorizar un código existente complicado ("Legacy Code"), ¿qué es indispensable tener?

Mover el código viejo a otra rama y empezar de cero

Aumentar el límite de memoria del servidor de producción

Permiso del cliente por escrito

Una suite de pruebas (tests automáticos) sólida para asegurar que los cambios no rompan el comportamiento existente

Pregunta 17 de 20

¿Qué es "Refactorización" (Refactoring)?

Mejorar la estructura interna del código sin cambiar su comportamiento externo

Añadir nuevas funcionalidades a código viejo

Arreglar bugs críticos en producción

Reescribir toda la aplicación desde cero en un nuevo lenguaje

Pregunta 18 de 20

¿Qué afirma la regla "Boy Scout Rule" aplicada al código?

Deja el código un poco más limpio de como lo encontraste al editarlo

Debes atar todos los hilos del programa antes de irte a dormir

El código debe estar preparado para sobrevivir en la nube

Siempre debes trabajar en parejas para vigilar el código del otro

Pregunta 19 de 20

¿Qué es la técnica del "Return Early" (Retorno Temprano) o "Bouncer Pattern" (Patrón de Guardia)?

Comprobar las condiciones de error o casos triviales al inicio de la función y hacer return inmediatamente, reduciendo la anidación (if/else)

Obligar al sistema a reiniciar temprano si falla la memoria

Salir a casa temprano después de hacer commit

Devolver variables sin inicializarlas primero

Pregunta 20 de 20

En el manejo de errores, ¿qué recomienda Clean Code frente a retornar "códigos de error" especiales (ej. return -1)?

Lanzar excepciones (Exceptions), ya que mantienen el flujo lógico separado del manejo de errores

Finalizar el programa abruptamente con exit()

Retornar null silenciosamente

Escribir el error en consola y retornar un string vacío

Completa tus datos para el ranking

Tu nombre o alias *

Correo electrónico

Quiero recibir tips de programación, nuevos tests y contenido exclusivo