Pero bueno, vamos con la siguiente charla. La siguiente persona que nos va a acompañar hoy es también una verdadera crack.
Se llama Yodra López, es software developer de Agile Monkeys. Me gusta mucho su contenido porque habla de buenas prácticas, de testing, de cómo hacer...
Bueno, cómo hacer un código que realmente no te vaya a dar vergüenza el día de mañana, como mucho del código que yo hago.
Así que vamos a darle la bienvenida a Yodra. ¿Qué tal, Yodra? ¿Cómo estás?
Muchísimas gracias. ¿Qué tal?
Nada, un placer. Estoy súper contento de tenerte por aquí.
¿Cómo has visto las charlas? Que te he visto ahí que estabas interactuando mucho, ¿eh?
Digo, ostras, Yodra a mí me está gustando.
Sí, sí, sí, qué guay. Estaba muy chula la charla de David.
Y nada, las otras las estaba viendo por Twitch y genial.
Muy bien.
Muy buena la que has montado.
Muchas gracias. Nada, esto gracias a la comunidad y ahí festejando el día de la programación.
Pues, Yodra, es muy interesante porque la charla anterior estábamos hablando justamente de testing,
pero tú nos traes una cosa como todo lo contrario.
Dice, ¿cómo hacerlo pero sin testing? Obviamente obligado, ¿no?
No porque queramos, sino porque nos han obligado un poco a que hagamos así, ¿no?
Bueno.
Vamos a ver qué sale.
Muy bien. Pues nada, te dejo a ti los mandos y que le des cañita.
Comparto tu pantalla y que vaya muy bien, Yodra.
Muchísimas gracias.
Bueno, como decía Miu, yo voy a hablar de refactorizar sin test y no moriré en el intento.
Bueno, vamos a ver qué sale de aquí.
No tengo presentación, mi nombre es Yodra, me pueden conseguir por ahí como Yodra López,
porque básicamente no tenemos casi tiempo y quiero contar muchas cositas.
Seguro que les suena o han vivido alguna vez esta historia de esta chica, por ejemplo, se llama Adasa y, bueno,
se levanta un martes por la mañana a tope de energía y con ganas de comerse el mundo,
de terminar el backlog y dejar todo funcionando, ¿no?
Y empieza, bueno, a revisar el backlog, a ver cuál es la siguiente tarea con la que tiene que trabajar.
Y se da cuenta que le toca la tarea.
Esa tarea en la que nadie del equipo quiere trabajar.
Básicamente porque esa tarea tiene que hacer un cambio de la funcionalidad en una parte del código que es bastante spaghetti.
Seguro que conocen este término.
Ese código embarañado que todos vemos como de lejos y no queremos tocar porque si tocamos algo fijo que rompemos, pues eso.
Y, bueno, dice Adasa, ¿y qué hago yo con esto?
¿Ahora qué hago yo?
Bueno, rezaré para intentar no romper nada.
Voy actualizando mi currículum, a ver si busco otro trabajo porque de aquí a lo mejor rompo algo muy importante y no lo cuento.
O, bueno, tenía que haber hecho mejor código.
Y esto suele ser una de las cosas que decimos muchas veces cuando vemos nuestro código una semana, días, meses después, nos pasa eso.
Dicimos, joder, esto lo podía haber hecho un poquito mejor.
Pues para ello no tenemos máquina del tiempo para viajar atrás y mejorar nuestro código, pero sí que tenemos una maravillosa herramienta que es el refactoring.
Y, bueno, refactorizar es cierto que tiene algunos peligros y entre ellos hasta que podemos romper nuestro código, podemos hacer refactores muy largos que nos alargamos ahí en el tiempo.
Empezamos a refactorizar una cosa muy pequeñita y poco a poco se nos va haciendo una bola porque queremos dejarlo todo impecable para subirlo de nuevo a producción.
En, durante ese refactor, al final acabamos dejándolo a medias ahí en un stash, en una rama perdida que luego nunca recuperamos.
Y al final no entregamos, o entregamos a última hora la tarea parcheando ahí a lo rápido porque no podemos mejorar ese código.
O directamente, pues, a lo mejor se nos va el tiempo y no llegamos a entregar valor en nuestro producto.
Pero, bueno, lo bueno de esto es que para estas cosas que estoy poniendo aquí hay soluciones.
Por ejemplo, para no romper nuestro código, no romper funcionalidades, podemos hacer testing.
Y para las otras tres yo las resumo rápido en focalizar.
Para mí, si hacemos algo muy pequeñito, enfocamos mucho el refactor en algo muy chiquitito, que podamos entregar muy rápido y siempre estar ahí en continua entrega, no vamos a dejar de entregar tareas.
Siempre vamos a estar aportando valor al producto, tanto en código como aportando valor para los usuarios que lo utilicen.
Y siempre vamos a poder dejar el código un poco mejor.
Pero sí, esto era refactorizar sin test y no lo hubiera intento.
Pero yo ya dije que tenemos que hacer test.
Pues, lo siento mucho.
Hemos sido engañados y sí, test siempre, por supuesto.
Si queremos dormir bien, si queremos, como dijo antes Debbie, irnos a tomar la cerveza tranquilos y no estar pensando en a lo mejor esto está roto, me llega un mensaje, hay alguien que no está pudiendo utilizar mi aplicación, etc.
Tenemos que hacer test.
Pero, ¿y refactorizar sin test se puede?
Vale.
Tenemos algunas herramientas que nos podrían ayudar a hacer algo de esta manera.
Como ya he dicho, quédense con que tenemos que hacer test, pero es verdad que hay ciertos casos en los que, bueno, a lo mejor no podemos o simplemente tenemos test y estamos súper cubiertos,
pero queremos hacer refactos en los que no nos pillemos las manos, en los que no tengamos que estar invirtiendo demasiado tiempo y hacerlo muy rápido para mejorar nuestro código y avanzar, ¿no?
Entonces, para eso tenemos cosas que nos facilitan la vida, como todo en desarrollo de software, más software, y herramientas que nos ayudan a hacer estos refactos de manera automática.
De esa manera, como humanos, no vamos a perder tiempo, perdón, no vamos a romper nada, ¿no?
Siempre nos equivocamos y de esta manera, utilizando un refactor automático, tenemos la certeza de que el líder no se va a equivocar, ¿no?
Pero, bueno, vamos al lío que yo quería aquí enseñarles cosas buenas.
Tengo un par de refactos, voy a empezar con invertir y eliminar condiciones.
Básicamente, los refactos que voy a poner son con JetBrains.
Y, nada, les voy poniendo al principio de cada uno el shortcut.
Pueden ir utilizando esto o, bueno, lo pondré por ahí también en Twitter, etcétera.
Entonces, invertir y eliminar condiciones.
Algo tan sencillo como un shortcut que nos tenemos que acordar simplemente.
Tenemos, por ejemplo, este código donde vamos a hacer ahí una creación de un usuario,
se le envía un email, etcétera, y se hacen unas comprobaciones.
Pero esto me huele un poco a que podemos ponerlo un poquito mejor.
Hay muchas intentaciones, etcétera.
Vale, pues, simplemente yéndonos al primer if y haciendo al enter,
invertir if condition, pasamos el throw directamente arriba, ¿no?
De esta manera ya, bueno, vamos reduciendo un poco y dejando arriba esas excepciones,
esas cláusulas guardas, esas cosillas que tenemos que hacer comprobaciones
antes de continuar con nuestro código, ¿no?
Y podemos ir directamente a Lens y eliminarlo y ya reducimos un nivel de indentación.
Parece una chorrada el nivel de indentación, pero es súper importante.
Cuando tenemos muchos niveles, es mucho más difícil leer nuestro código, etcétera.
Entonces, aquí ya se va mejorando un poquito.
Podemos volver a hacer lo mismo, simplemente al enter en el if y en el ens,
de nuevo, volvemos a invertir y volvemos a eliminar la condición.
Y ya pasamos del código de arriba que tenía más niveles de indentación,
al de abajo, donde directamente veo súper rápido.
Si no tengo username fuera, si no tengo el password fuera,
y si tengo esas cosas, voy a seguir creando mi usuario,
me dando un correo, etcétera.
¿Vale?
Siguiente refactor.
Aquí tenemos introduce parameter object.
En este caso no tenemos un shortcut específico, pero bueno,
hay una maravilla en IntelliJ que es control T sobre todas las partes del código que puedan
y siempre les va a salir las opciones de refactor que puedan hacer en ese momento exacto.
¿Vale?
Donde tengan el cursor en ese momento.
En este caso tenemos este código en el que, por ejemplo,
repetimos mucho los mismos parámetros que van pasando a lo largo de nuestras funciones.
La gran mayoría siempre recibe start on end date.
Pues lo que vamos a hacer aquí es simplificar esto para que simplemente pasemos un objeto
que englobe este concepto.
Aquí en este caso solo he puesto un ejemplo con dos parámetros,
pero vamos, podríamos, seguro que conocemos muchos casos en los que pasamos muchísimos parámetros.
¿Vale?
Entonces, seleccionamos los dos parámetros,
control T, introduce parameter object,
y directamente nos aparece un menú en el que podemos crear una nueva clase.
Aquí creamos una nueva clase, range date,
y directamente nos indica que ya cambia los dos parámetros por uno solo.
Si se fijan también, pone directamente el uso de este range date
y no tenemos nosotros que hacer nada más.
Pero nos quedan más casos.
Aquí sí que es cierto que tenemos que ir un poquito a mano,
ir nosotros a cada caso,
pero aquí directamente volvemos a hacer lo mismo,
seleccionamos, introduce parameter object,
y aquí lo que hacemos es decirle que nos seleccione,
nos utilice ya la clase creada.
Ya la tenemos creada, nos las utiliza,
y voilà.
Nuestro código mucho mejor.
Otro refactor.
Vamos a ver si este me da un poquito de tiempo,
porque vamos a ir ahí.
Move responsibility.
En este caso tenemos estas dos clases,
user and user service.
Y lo que estamos haciendo es calcular en el user service
la edad del usuario.
Vale.
Si les suena un poco lo que vamos a utilizar aquí
para refactorizar y dejar esto un poco mejor,
es tell donors.
Dile al usuario que directamente te diga qué edad tiene.
No vamos a calcular su edad.
No le vamos a pedir la fecha de nacimiento
para nosotros hacer el cálculo de la edad.
No, no, no.
Que el usuario me diga directamente qué edad tiene.
Entonces, aquí lo primero que vamos a hacer
es extraer a un método.
Para eso tenemos este shortcut de aquí.
Y lo mismo.
Si no, no sabemos los shortcuts.
Control, alt, perdón.
Control-T.
Y nos saldrá el menú de refactors
de los que disponemos.
Seleccionamos las dos primeras líneas
en las que se estaba creando un usuario
y añadiendo la fecha de nacimiento
y le damos al extract method.
Al extraer el método, nos queda algo así.
Tenemos nuestro método extraído
con la parte de la creación del usuario.
Por eso lo he llamado create.
Y, bueno, ahora lo que vamos a hacer
es pasar a estático estos métodos.
¿Vale?
Seleccionamos el método, make static
y pasamos a estático.
En este caso, te aparecerá un diálogo
donde puedes seleccionar todos los métodos
que quieras pasar a estático.
Los puedes hacer todos de golpe.
Los he hecho todos de golpe
porque, como les dije,
este refactor es de mover la responsabilidad.
Y lo que vamos a hacer
es mover la responsabilidad al user.
Y ahora, lo que hacemos es mover estos métodos.
Entonces, vamos a nuestro método.
Con F6 podemos mover los métodos directamente.
Vamos al método create, F6.
Seleccionamos ambos métodos, que están aquí.
Y hacemos el refactor.
Listo.
Tenemos ya el user service limpito.
Y nuestros métodos que habíamos creado,
bueno, el que ya teníamos de calcular la edad
y el create en la clase de user.
Aquí lo que vamos a hacer ahora
es borrar también ese código que ya no se utiliza,
esa clase de user service que no estamos utilizando.
Entonces, súper importante también utilizar el save delete.
No borrar a mano porque muchas veces nos puede pasar
que eso se está utilizando en otro sitio.
Entonces, no nos vamos a dar cuenta.
Por ejemplo, en este caso,
user service se está utilizando en los tests.
Es verdad que la variable no se utiliza para nada,
pero está aquí la instancia, ¿no?
Entonces, lo que hacemos es vamos a esa instancia
que ya sabemos que no se está utilizando
porque nos aparece en gris,
save delete y la eliminamos.
Vamos a nuestro user service que ahora
nos aparece también en negrito
y lo mismo, save delete y lo eliminamos.
Y nuestro código quedaría algo así.
Arriba tenemos los tests
y debajo, ¿cómo quedaría la clase de user service?
Ya, perdón, la user service ya no la tenemos.
Y, bueno, esto ya puede subir a producción.
Estaría fantástico y maravilloso.
Es cierto que este código se puede mejorar un poco más.
Tengo un par de reflectos por ahí
para continuar mejorando este código un poquillo,
pero lo dejaré para otro momento
porque hoy no va a dar tiempo.
Eso sí, con todo esto,
en lo que llevamos de tiempo, ¿qué hacemos?
¿Ya yo sé refactorizar y utilizar el refactor automático?
No, por supuesto.
Pero lo que yo quiero que se lleven de aquí
es básicamente que tenemos que hacer mejor código,
tenemos que pararnos un poquito
que por un minuto de pensar un poquito más
no vamos a perder demasiado tiempo
en entregar una tarea
y podemos mejorar mucho nuestro código.
Pensar, por supuesto,
que no hacemos el código para nosotros,
sino para otros compañeros
que también van a leer ese código.
Como no, hacer test.
Hacer reflectos automáticos muy pequeñitos.
Estas tonterías, simplemente un invertir condición,
un renombrar un método,
extraer una variable, etcétera,
eso ya nos aporta muchísimo valor
para tener nuestro código mucho más legible.
Por supuesto, hacer test.
Refactos muy, muy, muy pequeñitos, ¿vale?
Automáticos y pequeñitos.
Como no, hacer test.
Y bueno, para tener en cuenta
el tema del refactor automático e interiorizarlo,
yo lo que suelo hacer es repetirlos.
Muchas veces, cuando estoy trabajando
y a lo mejor quiero hacer algún tipo de refactor
y lo hago manual, deshago.
Deshago directamente, ¿qué?
Son, ¿qué?
Unos segundos, deshacer lo que acabo de hacer a mano
para intentar hacerlo con el IDE
y que el IDE directamente lo haga automáticamente.
Ya eso te hace que te vayas quedando.
¡Ay! Se me había olvidado.
Está el rename.
Vale.
Voy a deshacer el rename que acabo de hacer a mano
y que tengo que ir uno a uno
y hago un rename con el IDE.
Por supuesto, el Control-T.
El Control-T es el mejor y alleado
cuando estás empezando a hacer refactores automáticos.
Por supuesto, estás en JetBrains.
Control-T y nos sale directamente la chuleta
de todos los refactores que podemos realizar.
Y por último, tomar notas
y tener nuestra chuletita de shortcuts.
Si quieren ver alguna,
en mi página web tienen una chuleta de shortcuts
y por ahí iré subiendo vídeos del contiguo a este
y de todos los refactores que hemos estado haciendo.
Muchísimas gracias y nada.
¡Pim, pam!
Muchas gracias, Yodra.
La gente está sorprendida.
No me esperaba ver hoy Java,
pero estoy contenta.
Estaba mi fila por ahí.
Sabía que te iba a gustar.
A mí personalmente me has recordado cosas
que no quería recordar.
Es decir, que los refactores automáticos
están para todos los ideas,
toda la familia de ideas de JetBrains,
pero que ya va a ser un lenguaje más estricto,
pues tiene muchos más refactores que realizar.
Pero para JavaScript también se puede hacer bastante.
Buenísimo.
Buenísimo.
Oye, pues muchísimas gracias.
Había un sorteo, Yodra,
de una licencia de IntelliJ.
JetBrains.
Yo me los voy llamando poco a poco.
Bueno, como si yo trabajara en JetBrains.
Pero bueno, de alguna forma habrás conseguido la licencia.
¿Te la han pasado por debajo de mano?
No puedo contarlo aquí.
No puedo contar los detalles.
Se cayó de un camión.
Se cayó de un camión.
Eso es un poco raro.
Vale, pues a ver,
¿qué palabra quieres que hagamos
para el sorteo?
Elige una palabra.
Adalove Depp.
Adalove Depp.
Adalove Depp.
A ver si me va a costar a mí.
A ver, creo que lo he puesto bien.
A ver, lo voy a poner
para que me confirmes que lo he puesto bien.
¿Vale?
Es este, Adalove Depp.
No, con Lube.
De desarrollo.
Ay, perdón.
No, no.
Sí he sido yo que la he liado sin querer.
Que es que están al lado.
Y como lo tengo en dos pantallas,
ahora sí.
Ahí lo tenía bien,
pero aquí lo he puesto mal.
Adalove Depp.
¿Vale?
Vale, pues ponéis esta palabra
y vais a aceptar en el sorteo
de una licencia de un año
para JetBrains.
O IntelliJ.
Exacto.
O las dos cosas.
JetBrains.
Para todo.
Para todo.
Para todo.
Vale, pues Adalove Depp.
Ahí lo ponéis todo en minúscula.
¿Vale?
Y ahí tenéis el sorteito.
¿Ok?
Bueno, pues muy bien.
Nos has engañado.
Yo pensaba, ah, sin test.
No sé, ¿cómo lo haría?
Bueno, pero es una forma,
si te lo hace automático el líder,
tú te lo...
Sí, sí, sí.
No es cosa tuya, es verdad.
Tienes toda la razón.
Tienes toda la razón.
O sea, no eres tú que lo haces.
No, no voy a decir yo que hablo también mucho de testing,
que no hagamos test, ¿no?
Claro, claro.
No, no.
Tienes toda la razón.
Vale, pues vamos a darle.
A ver a quién le toca.
Vamos a darle y le toca a Elia.
Elia, Eli, guión bajo, YY, A.
Elia, Elia, felicidades, que te ha tocado.
Ya nos pondremos en contacto contigo.
Mira, dice, sí, sí.
Uy, sí.
Pues nada, felicidades, me alegro, hombre, mucho.
Y dice, Dios, dice, Dios, Dios.
No sé, no sé a quién le está rezando y tal.
Bueno, Yodra, pues, oye, muchísimas gracias por haberte pasado
y por haber compartido esto que me ha parecido súper interesante.
Muchísimas gracias a ti por este ratito y por dejarme estar aquí.
Nada, o sea, solo faltaba.
Así que nada, ha sido un verdadero privilegio tenerte.
Muchas gracias, un abrazo enorme.
Cuídate.
Bye, bye.
Bye.
Pues teníamos a Yodra y esto es que no para, no para,
porque vamos con los tiempos.
Me sabe fatal porque tengo aquí ya el line up.