La semana pasada trabajamos en cómo analizar nuestro nuevo formulario de artículos, aunque con excepciones NullPointer para manejar datos faltantes o inválidos.
El comentario que recibí de David Denton, uno de los desarrolladores de http4k, fue: “¿Sabes que puedes usar las lentes de formulario aquí y evitar toda esta tontería?”
Así que en este episodio refactorizaremos el código actual para usar lentes de formulario y veremos cuánta tontería realmente evitamos.
Momentos significativos
* 00:00:38 Encontramos dos errores
* 00:01:35 Recrear un error en las pruebas
* 00:04:00 Arreglar el error lo más rápido posible
* 00:04:47 Refactorizar para mejorar las cosas
* 00:05:36 Agregar algunas pruebas para otras cosas que podrían no funcionar
* 00:06:15 Funcionan, así que hacer commit
* 00:06:27 Revisar nuestra implementación y nuestras pruebas
* 00:07:26 Refactorizar nuestras pruebas para revelar la intención
* 00:09:40 Refactorizar el análisis para usar lentes
* 00:13:21 El asistente de IA resulta útil
* 00:15:17 Error de refactorización en IntelliJ
* 00:21:23 Error de http4k
* 00:23:49 Usar lentes para diagnosticar múltiples fallos
* 00:24:37 Inline y extraer para refactorizar a mejores semánticas
* 00:30:17 Generar un evento para fallos de análisis
* 00:31:22 Callback al episodio Errores son Eventos
* 00:31:25 Crear un matcher personalizado de Hamkrest
* 00:38:02 Hacer commit
* 00:38:14 Revisar
* 00:38:46 Arreglar el error donde tenemos dos formularios entrelazados
* 00:41:19 Revisar
Esta es la parte 86 de una exploración de hacia dónde podría llevarnos una implementación de Desarrollo Guiado por Pruebas del sistema de control de stock Gilded Rose en Kotlin. Puedes ver toda la serie como una lista de reproducción
y el código en GitHub
Si te gusta esto, probablemente te gustará mi libro Java a Kotlin, Una Guía de Refactorización
(
http://java-to-kotlin.dev). Se trata de mucho más que solo las diferencias de sintaxis entre los lenguajes: muestra cómo actualizar tu forma de pensar a un estilo más funcional.