aitorevi

1ª semana en Lean Mind

Solo tengo palabras de elogio para esta empresa. La organización de las prácticas es buenísima. Todo está pensado de antemano. Es como si las hubieran codificado con TDD, para que tengan muy buena cobertura de test y haya los menores fallos a la hora de ejecutarlas.

Te hacen sentir cómodo, relajado y a la vez te motivan para que des lo mejor de ti. Nunca estás solo, siempre hay alguien para apoyarte y ayudarte a dar tus primeros pasos hacia adelante.

Destacar esta semana la jornada de formación con los compañeros de Lean Mind. Fue dura porque había muchos conceptos nuevos en la Kata pero a la vez muy productiva porque nunca había pensado como se podía testear una consola. Jonay me ayudó a entender como lo había hecho. Gracias compi.

Después de dos días

Hoy es el tercer día, estoy super contento formando parte de estas practicas. Mi mentor, Kevin, se esfuerza por ayudarme en que aprenda, me da confianza y me reta a hacer cosas que no pensaba que pudiera hacer. Aún estando en remoto, me siento acompañado en todo momento. La forma de trabajar, conexiones entre nosotros, con Fran, con Yazmina y más adelante según se vayan uniendo compañeros a las practicas, hace que me sienta arropado y con muchas ganas de avanzar. Espero con muchas ganas que llegue el viernes para hacer la formación con el instituto Cesar Manrique.

Este lunes empezamos 🎉🎉

No queda nada para empezar a caminar, a recorrer un camino diferente, nuevo en muchos aspectos. Tengo ganas de ver de nuevo a personas que ya conozco, no en persona aún, aunque espero que pronto podamos vernos.

Quería dar las gracias a todas antes de empezar porque me han ayudado a estar aquí hoy escribiendo estas palabras.

Primero a mi familia que sin dudarlo me ha apoyado, creen en mi y me van a ayudar a emprender esta nueva etapa. Sin su apoyo incondicional no hubiera podido hacerlo. También a Carlos y a María, que hicieron desaparecer cualquier duda o temor dando valor a habilidades mías que nunca hubiese pensado que fueran importantes en el trabajo de desarrollador. Me animaron a perseguir mi sueño, a cambiar el rumbo de mi vida y me dieron la fuerza extra para ello. No quiero olvidarme de mi tutora Heike, que cuando se reunió conmigo para que le explicara mi situación me ayudó sin dudarlo y gracias a ella esto es posible. Y como no, Yazmina y Fran, dos encantos de personas, amables, profesionales, atentas, en definitiva, una maravilla. Me han hecho fácil todo el proceso, manteniéndome siempre informado, ofreciéndose a ayudarme en lo que necesitara y haciendo que aún sin haber empezado, sienta que lo que importan son las personas.

Este lunes «Comenzamos a picar».

Comentarios en el código

Los comentarios no tienen que explicar lo que hace el código, tienen que aclarar el porqué se ha escrito así ese código.

Con un código limpio, con nombres de clases, variables etc… claros y concisos, esto hace que el código esté auto-documentado. No hay necesidad de añadir comentarios. Si el código es complejo, reescribe lo, no lo comentes.

Los comentarios quedan obsoletos con el tiempo, cuidado que pueden ser un arma de doble filo.

Para legacy code, es más interesante comentar lo que hemos averiguado sobre su funcionamiento antes de refactorizarlo. Si estás trabajando sobre una parte de código que sigue en funcionamiento, es interesante poner algún comentario que indique que estamos refactorizando esa parte de código.

También puede ser interesante comentar algunos requisitos no funcionales para quien pueda verlo entienda las limitaciones del sistema, por ejemplo el orden de algunas lineas que es necesario para cierto funcionamiento, limitaciones en alguna función que pueda hacer que se llene el disco si se ejecuta, etc…

Fuente: Podcast Ni cero, ni uno

Refactoring

«Modificar el código para que cambie la forma que esta codificado sin que cambie su comportamiento. Mantenga la misma funcionalidad y que su implementación sea la diferente». Martin Fowler.

Lo recomendable es hacer refactor 30 minutos cada día al empezar la jornada. Mirar los nombres de las variables, métodos o clases que nombraste ayer es muy interesante. Buscamos código que tenemos que tocar por que tenga bugs o cualquier otra cuestión y vamos a aprovechar para refactorizarlo.

Si ha una parte que funciona, algo que se está utilizando hace años y no ha dado ningún problema, no lo toques.

Prestar atención a los puntos de ejecución comunes, condicionales, mutación de estados o dependencias, estos puntos son propensos que haya errores al refactorizar. Hay que tener tests antes de refactorizar.

Hacer los cambios uno a uno, ser metódico en esto y cada cambio que hagas, hacer un commit para guardar puntos de restauración seguros.

En legacy code apoyarse en pair programming para obtener un resultado mucho mejor.

Extraer alguna funcionalidad en métodos más pequeños que hagan una sola cosa nos ayudará a entender mejor y poder mantener mejor en el futuro nuestro código.

Fuente: Podcast Ni cero, ni uno