Seguir aprendiendo: leer el código fuente, ver los episodios y un plan de dominio continuo

Hay una asimetría incómoda al terminar un track largo: sabes más de lo que puedes demostrar y menos de lo que crees. La única cura conocida es dejar de consumir material y empezar a re-derivar, y para eso hacen falta tres cosas que esta lección entrega en orden. La primera es aprender a leer código de bibliotecas, que es la habilidad de mayor rendimiento de toda la profesión y la que menos se enseña: TCA cabe en una tarde de lectura si se abre por los archivos correctos, y en un mes de frustración si se abre por el índice. La segunda es saber qué material existe y qué pregunta responde cada pieza, para no ver ocho horas de vídeo buscando algo que estaba en un artículo. Y la tercera es un plan, porque el dominio no llega por acumulación sino por repetición dirigida sobre las partes que todavía no puedes reconstruir de memoria.

Leer el código fuente en el orden correcto

TCA es una biblioteca legible, pero solo si se entra por donde debe. El error universal es abrir Store.swift o TestStore.swift, que son los archivos más grandes y los que suponen conocido todo lo demás. El orden que funciona va de la abstracción a su implementación y de ahí al runtime, y en los primeros cuatro archivos ya está la tesis completa; lo demás es ingeniería para que la tesis sobreviva al mundo real.

git clone https://github.com/pointfreeco/swift-composable-architecture
cd swift-composable-architecture/Sources/ComposableArchitecture

# El orden de lectura, de menos a mas presupuesto de contexto
wc -l Reducer.swift Reduce.swift Effect.swift Scope.swift Store.swift TestStore.swift

La segunda mitad de la habilidad no es leer el código sino leer su historia. Cuando un fragmento parezca arbitrario —una comprobación extraña, un @inlinable inesperado, una copia defensiva— la pregunta útil no es qué hace sino qué incidente provocó esto, y esa pregunta tiene respuesta mecánica en el repositorio.

# Quien introdujo esta linea y en que commit, con el mensaje completo
git log -L 40,60:Store.swift

# Cuando aparecio y cuando desaparecio una idea concreta en toda la historia
git log -S "cancellable" --oneline -- Sources/

# La documentacion oficial vive en el propio repositorio, no solo en la web
ls Sources/ComposableArchitecture/Documentation.docc/Articles

Queda una tercera técnica, y es la que disuelve la sensación de magia que dejan las macros. El código que @Reducer y @ObservableState escriben por ti es Swift corriente y se puede ver: en el editor, desplegando la expansión desde el menú contextual de la macro; en la línea de comandos, pidiéndole al compilador que la vuelque. Media hora leyendo esa expansión retira para siempre la idea de que ahí ocurre algo que no podrías haber escrito a mano.

# Volcar lo que las macros generan, para leerlo como codigo normal
swift build -Xswiftc -dump-macro-expansions

El material de Point-Free y qué pregunta responde

El catálogo es enorme y desordenado si se aborda cronológicamente, porque abarca años y varias reescrituras de la propia biblioteca. Ordenado por pregunta, en cambio, es sorprendentemente compacto. La regla práctica es no empezar por la serie de la arquitectura: casi todo lo que hace única a TCA se explica mejor en las series que la preceden, donde las ideas aparecen aisladas y sin el peso del framework.

Conviene además saber cómo se consume ese material sin perder la tarde. Buena parte del catálogo es de pago, pero hay episodios abiertos en cada serie y, sobre todo, cada episodio publica su transcripción completa y el proyecto de código de cada paso; para una duda concreta, buscar en la transcripción y abrir el proyecto es diez veces más rápido que ver el vídeo entero. La disciplina que mejor funciona es no ver nada sin una pregunta escrita de antemano y cerrar el episodio en cuanto esa pregunta tenga respuesta.

Al material en vídeo hay que añadirle dos fuentes que se consultan más y se citan menos. La primera son las guías de migración en la documentación del repositorio, que son la única explicación honesta de por qué una API se sustituyó por otra y qué se aprendió en el intento. La segunda son las apps de ejemplo, con SyncUps como pieza central —una reconstrucción completa de una app de Apple— y con el juego isowords como muestra de una base de código real, grande y publicada entera, incluido su servidor.

flowchart LR
L[Leer fuente] --> C[Construir algo pequeno]
C --> R[Re-derivar sin mirar]
R --> E[Ensenar o escribir]
E --> D[Detectar el hueco]
D --> L
D --> P[Contribuir o preguntar]
P --> L
style L fill:#89b4fa,color:#11111b
style R fill:#fab387,color:#11111b
style E fill:#a6e3a1,color:#11111b

Noventa días de práctica deliberada

Un plan sirve si tiene entregables comprobables y si cada semana ataca algo que todavía no puedes hacer sin ayuda. El que sigue está diseñado con esa regla y con una segunda, más dura: nada cuenta si se hizo mirando la solución. Reconstruir con el modelo delante es leer; reconstruir sin él es aprender, aunque tarde el triple.

// Semana 4, entregable: escribe esto de memoria antes de abrir la documentacion
@Reducer struct Feature {
  @ObservableState struct State: Equatable { }
  enum Action { }
  var body: some ReducerOf<Self> { Reduce { state, action in .none } }
}
// Si dudaste en la firma de body o en el retorno del Reduce, ahi esta tu hueco

La última fila es la que casi todo el mundo salta y la que más rinde. Responder la duda de otra persona te obliga a construir un ejemplo mínimo, a comprobar que compila y a estar en lo cierto delante de alguien que puede contradecirte; es práctica deliberada disfrazada de amabilidad. Y la contribución más fácil de que te acepten no es una función nueva sino una corrección de documentación, que exige entender exactamente igual de bien y no arriesga nada del diseño ajeno.

Mantenerse al día sin perseguir versiones

La biblioteca se mueve, y con ella todo el ecosistema. La estrategia sostenible no es actualizar por deporte sino tener un criterio para decidir. Ante una novedad, la pregunta útil no es si es elegante sino qué categoría de error elimina: si la respuesta es ninguna, pero se escribe más corto, puede esperar sin coste; si la respuesta es hace imposible un estado que hoy puedo construir, entonces conviene adoptarla pronto, porque su valor crece con cada línea que escribas sin ella.

# Que subiria y hasta donde, sin tocar todavia el lockfile
swift package update --dry-run

# Cada version mayor trae su guia de migracion dentro del propio repositorio
ls Sources/ComposableArchitecture/Documentation.docc/Migration*

Las deprecaciones de esta biblioteca vienen casi siempre con el reemplazo indicado en el propio aviso, de modo que la mayoría de las migraciones se resuelven aplicando las correcciones automáticas del editor y leyendo el artículo correspondiente para los tres casos que no se pueden automatizar. Silenciar esos avisos es la decisión que convierte una tarde de trabajo en una semana, porque el aviso desaparece pero la API antigua sigue caducando igual.

Hay además un sitio donde preguntar y un modo de hacerlo. Las discusiones del repositorio son el canal principal y están muy bien atendidas por los propios autores, con una condición implícita que conviene respetar: una pregunta acompañada de un caso reducido —una feature de treinta líneas y un test que falla— recibe respuesta casi siempre, y una pregunta descrita en prosa sobre un proyecto que nadie puede ejecutar casi nunca. Reducir el caso es, de hecho, el ejercicio que más veces resuelve la duda antes de llegar a publicarla.

El resto es higiene conocida: fijar versiones en el manifiesto, actualizar en una rama propia y con las pruebas verdes antes de tocar nada, leer las notas de versión completas en lugar del titular, y tratar cada aviso de deprecación como trabajo pendiente y no como ruido. Un proyecto que hace esto se mantiene indefinidamente al día con un esfuerzo pequeño y constante; uno que lo pospone acumula una migración de tres versiones que nadie quiere empezar y que acaba justificando, años después, la decisión de no volver a usar bibliotecas externas.