Comprensión durante la lectura
¿Por qué el autor recomienda abordar la migración por iteraciones en lugar de hacerlo todo de una vez?
Es más fácil migrar 30 minutos al día por varios días, que dejar la aplicación rota un largo tiempo mientras se arreglan todos los errores. Para esto, activar el "chequeo" estricto de swift, arreglar algunos "warnings" y luego volver a apagarlo.
¿Qué significa hacer los tipos "Sendable por defecto" y por qué es relevante para equipos de trabajo?
El nuevo código debe escribirse conformando Sendable por defecto y usando async/await. La idea es no usar el paradigma viejo en el código nuevo.
¿Cuándo y por qué debería usarse el modo Swift 6 en proyectos nuevos, aunque el proyecto principal aún no haya migrado?
Activar Swift 6 temporalmente y revisar que el código nuevo pase la validación. De esa forma se evita aumentar la deuda técnica y que crezca el scope de la migración.
¿Por qué el autor advierte en contra de refactorizar durante la migración, si en principio refactorizar es algo positivo?
El autor sugiere concentrarse en hacer la migración a Swift 6 y no hacer ningún refactor en el camino, a no ser que el refactor sea algo bloqueante para la migración.
¿Qué ventaja tiene abrir pull requests pequeños y enfocados durante el proceso de migración?
Los PRs grandes son más difíciles de revisar y menos probable de ser integrados rápidamente. Por esto, si se actualizó una sola clase a Swift Concurrency, es buena idea abrir un PR e integrarlo en la rama feature/swift-6-migration. Esto es un checkpoint pequeño durante la migración y es una medida de progreso.
¿Cuál es el riesgo de abusar del atributo @MainActor y en qué casos sí tiene sentido usarlo ampliamente?
La mayor parte de aplicaciones pueden tener @MainActor por defecto activado. Sin embargo, no siempre es buena idea marcar absolutamente todo con @MainActor, sino que conviene pensar si se puede aislar el código en otro actor.
Top comments (0)