Code Review en Swift: 10 cosas que reviso primero

Entrenador de Python en Línea para Principiantes

Aprende Python fácilmente sin sobrecargarte de teoría. Resuelve tareas prácticas con verificación automática, recibe pistas y escribe código directamente en el navegador, sin instalar nada.

Start Course

Por qué el Code Review en Swift no es cuestión de ser quisquilloso

Imagina esta situación: abres el pull request de un colega, ves 500 líneas de código Swift y te das cuenta de que en 20 minutos comienza la daily. ¿Te suena familiar? El code review (o revisión de código) no es una competencia de "quién encuentra más errores tipográficos". Es tu oportunidad de prevenir bugs en producción, mejorar la arquitectura y transmitir conocimientos al equipo.

En este artículo he recopilado una lista de verificación de code review para Swift que yo mismo utilizo. Sin rodeos: solo comprobaciones concretas, ejemplos de código y explicaciones de por qué son importantes. Incluso si programas en Python pero te asomas al mundo del desarrollo iOS, el material te será útil.

\n\n

1. Seguridad de memoria y tipos opcionales

Swift se enorgullece de su seguridad de memoria, pero eso no significa que puedas relajarte. El problema más común es el force unwrapping. Cada signo de exclamación es un posible fallo.

\n\n

Qué revisar:

Force unwrap (!) — solo es aceptable en pruebas o cuando estás 100% seguro del valor. En código de producción, es una bandera roja.
IUO (Implicitly Unwrapped Optionals) — úsalos solo para IBOutlet o propiedades que se inicializan después de init, pero antes del primer uso.
Ciclos de retención (retain cycles) — verifica los closures en busca de [weak self] o [unowned self].

\n\n

// Mal: force unwrap sin verificación\nlet url = URL(string: "https://pythonlib.ru")! // Fallo si la cadena no es válida\n\n// Bien: guard let\nguard let url = URL(string: "https://pythonlib.ru") else {\n    print("URL no válida")\n    return\n}\n\n// Verificación de ciclo de retención en closure\nclass NetworkManager {\n    var completionHandler: (() -> Void)?\n    \n    func fetchData() {\n        completionHandler = { [weak self] in\n            guard let self = self else { return }\n            self.updateUI() // self ahora es una referencia débil\n        }\n    }\n    \n    func updateUI() { /* ... */ }\n}\n

\n\n

Consejo para code review: si ves !, pregunta "¿por qué no hay un guard o if let aquí?". Esto evitará muchas caídas.

\n\n

2. Manejo de errores: no te tragues las excepciones

Swift ofrece un potente mecanismo do-catch, pero los desarrolladores a menudo lo ignoran. Un antipatrón típico es try! o un catch vacío.

\n\n

Qué revisar:

try! — casi siempre es malo. Solo si estás escribiendo una prueba.
catch {} vacío — simplemente estás perdiendo información sobre el error. Como mínimo, regístralo.
Propagación de errores hacia arriba (throws) — la función debe manejar el error o propagarlo explícitamente.

\n\n

// Mal: nos tragamos el error\ndo {\n    let data = try fetchData()\n} catch {\n    // No hacemos nada — el error se pierde\n}\n\n// Bien: registramos y mostramos al usuario\ndo {\n    let data = try fetchData()\n    updateUI(with: data)\n} catch let error as NetworkError {\n    showAlert(message: error.localizedDescription)\n} catch {\n    print("Error desconocido: \\(error.localizedDescription)")\n    showGenericError()\n}\n

\n\n

En el code review para Swift, verifica siempre que Error no se ignore simplemente. El usuario debe entender qué salió mal.

\n\n

3. Arquitectura: ¿MVC, MVVM o VIPER?

No importa qué patrón hayas elegido, lo importante es que el código lo siga. En el code review ves si el ViewController se ha convertido en un "God Object" (una clase que lo hace todo).

\n\n