Hace más de dos años escribí un post sobre los pasos que tomé para buscar trabajo como informático en Londres. Ese post ha resultado ser el más popular de mi blog con diferencia, y a partir de él he sido contactado varias veces solicitando información adicional, preguntando dudas, etc.
Recientemente un lector me escribió con la intención de recibir feedback sobre su CV, lo que me dio la idea de plasmar en un post los consejos que habría podido darle a él personalmente, para así poder ayudar a más personas.
Mi relación con el refactoring viene de lejos, de hecho entre los primeros posts que publiqué se encontraba una serie de tres donde analizaba de forma algo crítica el libro “Refactoring” de Fowler, y que seguramente hoy día escribiría de forma diferente.
Al cabo de los años he llegado a definirme a mí mismo, medio en coña medio en serio, como un “yonki del refactoring”. En efecto, refactorizar código y dejarlo apañado es una de las tareas que más disfruto en mi día a día como desarrollador, tanto que hubo un momento determinado en que quizás hasta llegué a pasarme.
En este post voy a describir cada una de las etapas que he atravesado en mi relación con el refactoring. Supongo que muchos de vosotros os veréis reflejados en algunas de ellas.
Supongo que a nadie le pillará por sorpresa si afirmo que el desarrollo Agile está en boca de toda las empresas hoy día. Incluso el tema se está llevando a otra dimensión con el deslumbrante nombre de “Transformación Digital”. Por tanto, no creo que sea necesario explicar en este post qué es el desarrollo ágil.
El asunto ha llegado al nivel de que no es difícil encontrar ofertas donde se buscan “Agile Developers”, y aquí es donde el asunto empieza a cobrar tintes algo cómicos. Personalmente, no creo que casi ninguna empresa que publica una oferta con ese título tenga mucha idea de las skills que diferencian a un programador ágil de uno que no lo sea, y si lo afirmo con tanta rotundidad es porque nunca he visto mención alguna a las que yo creo son las habilidades principales que todo desarrollador ágil debe tener.
Acabo de terminar mi primera experiencia como Anchor (aka Team Leader). Hacer un buen trabajo en este rol era uno de mis objetivos del año 2017, y creo que lo he conseguido. Quizás no haya sido el mejor proyecto para empezar, por varios factores que no vienen al caso, pero en general estoy muy satisfecho con todo lo hecho y aprendido.
Me gustaría recoger en este post varias conclusiones que he ido sacando, así como algunas lecciones aprendidas. A lo mejor os parece que no digo más que obviedades. Bien, llevo trabajando muchos años, y muchas de estas cosas no las he visto poner en práctica tanto como podéis pensar.
Tenía pendiente escribir la última parte de esta serie desde hace tiempo. Tras revisar cómo Git gestiona merge y rebase, queda por ver la forma en que Git gestiona la capa de distribución, es decir, el trabajo y sincronización con repositorios remotos.
Como ya sabemos, Git es un sistema de control distribuido de versiones, donde cada persona no tiene más que una copia completa del repositorio. Es decir, cada usuario que clone un repositorio Git tendrá una copia de la carpeta .git, carpeta que contiene montones de cosas, según vimos en anteriores posts de la serie.