Aprendiendo en PHPSevilla, experiencia de mi primera charla sobre Refactoring en PHP

Este es un post que tenía ganas de escribir. El 13 de junio, aprovechando que estaba de paso por Sevilla por vacaciones, estuve en dando una charla sobre refactoring en PHP con los amigos de PHPSevilla.

img-1

Lo primero agradecer a la Agencia Inn ofrecernos el espacio para dar la charla (por cierto la oficina mola), gracias a los organizadores de PHPSevilla (gracias Miguel por dejarme el portátil) y gracias a todos los que asististeis a la charla por la acogida.

El resumen corto: genial. Es estupendo encontrar gente con tus mismas inquietudes y creo que iniciativas como esta son ideales para conocer compañeros de profesión y aprender. Además, era la primera vez que estaba al otro lado dando una charla, así que como ya he dicho genial.

Seguir leyendo “Aprendiendo en PHPSevilla, experiencia de mi primera charla sobre Refactoring en PHP”

No sólo escribimos código

No solo escribimos código, tenemos issues en Jira, sprints, notificaciones de slack, notificaciones por gmail, emails, daily scrum, reuniones… por lo que también tenemos que aprender a relacionarnos con nuestro entorno. Al principio era una de las cosas que más me costaba, por eso me gustaría compartir algunos “trucos”/enseñanzas que he ido aprendiendo y que intento aplicar para tratar con todo estos inputs que no tienen que ver con el código.9716532277_dca37808b0_z.jpg

Email Inbox

Nadie te enseña a gestionar el correo, me llegan un montón de emails, las pull request, las issues de Jira, notificaciones de reunión, emails de subida,… todos los emails llegan a la bandeja de entrada pero ¿qué hacemos después? A mi me encantan los filtros, las etiquetas y las carpetas para tenerlos todo más o menos ordenado y que solo lleguen al inbox lo que de verdad importa. El objetivo que me tengo es que las notificaciones no me “molesten” y que sea yo quien vaya a ver los emails cada vez que lo necesito. Os cuento como lo hago. Seguir leyendo “No sólo escribimos código”

Mejorando el naming de nuestro código

$result, $resultado, $request, $fecha, … es cierto, poner nombres a las variables y/o los métodos es una de las cosas más difíciles cuando estamos programando. Llegar a poner un buen nombre, establecer cada cosa en su sitio y crear las abstracciones correctas a la primera es un poco complicado. Y mucho más si estamos refactorizando. No te preocupes, el naming es un proceso, no se consigue a la primera.

16292355113_47a1de1b90_z

Este post recopila una serie de trucos, consejos y de cagadas que cometo a la hora de poner nombre o de cambiar los nombres a partes del código.

Las etapas del naming

Buscando en Internet sobre naming y como mejorarlo, me encontré con esta joya Good naming is a process, not a single step una serie de posts sobre como mejorar el naming del código y en especial del legacy code. En esta serie de post Arlo Belshee (el autor) indica que normalmente el camino a recorrer para encontrar un buen nombre es este:

  • Missing
  • Nonsense
  • Honest
  • Honest and Complete
  • Does the Right Thing
  • Intent
  • Domain abstraction

Cambiar el nombre de un trozo de programa es un proceso lento, miro una parte del código, intento entender que está sucediendo, tengo una idea de como renombrar/extraer una parte de la funcionalidad y lo hago. Repito este proceso hasta que los nombres sean consistentes y he llegado a un punto en el que esto estoy contento.

Esto parece fácil, pero cuando estoy delante de legacy code se hace cuesta arriba, por eso intento cambiar los nombre poco a poco, aunque sea un foreach, ya que creo que trabajando el naming se mejora la comprensión del código y con ello se paga parte de la deuda técnica.

Este enfoque puede parecer extraño al principio. Después de todo soy programador, sé leer código complejo y mi trabajo es actualizar/mejorar ese código. Pero también es cierto que donde más tiempo invertimos los programadores es en leer código, incluso más que en escribir código, más que en diseñar, más que en reuniones… Por ello creo que una buena manera de pagar la deuda técnica y mejorar nuestro código es escribiendo buenos nombres y renombrando cada poco. Ya que nos haremos más eficientes porque leer el código nos será más sencillo.

Pasos a seguir

  • Mirar: no trato de entenderlo todo al 100%, ya que eso me tomaría mucho tiempo e incluso puede que se me fría el cerebro.
  • Idea: no es la mejor, pero al menos es algo, inspecciono la idea.
  • Escribir: Escribo ese nombre, veo como queda, utilizo thesaurus.com para los sinónimos
  • Chequear: Compruebo como queda y si es consistente con las decisiones que he tomado antes o las que creo que tomaré. Inspecciono el impacto ¿Es fácil de buscar, sabré dentro de 2 semanas que es esto, el equipo está de acuerdo?
  • Commit: Hacer un commit, con un mensaje bueno sobre el renaming. Intentar no poner “refactor”

¿Y si no encuentro un buen nombre? Pues no pasa nada, intento no frustrarme y seguir hacia delante. Si aun así necesito poner un nombre a algo llamo a esa variable/método Manolo, Joselito, Amalia, nombres que choquen, para así cuando tenga más conocimiento del problema ir a ellos y poder cambiarlos de manera sencilla.

Un pequeño ejemplo

Imagina que nos encontramos con un método como este en un controlador, o mejor en una vista.

$this->preload();

¿Qué hace este método? Podría leer un XML de un servicio, podría cargar datos de una base de datos, o no se cualquier cosa porque leer ese nombre nos hace tener que ir a la función para ver lo que hace.

Tenemos que caminar hacia la honestidad, poner que es lo que hace aunque no tengamos muy claro del todo todo lo que hace

$this->doSomethingWithDBAndDisplayResult();

Esta honestidad también se puede aplicar a las clases porque tener una clase que sea DataManager, ¿manejar los datos de qué?

Poco a veremos que es lo que hace el método y podremos darle el nombre completo y honesto:

$this->parseXMLAndStoreInMemcacheData();

Ahora podemos empezar a encapsular este método en otros más pequeños y seguir con nuestra refactorización, continuar caminando y mejorando nuestro código.

Esto mismo también lo intento aplicar a los test, tener un test que sea testOk, pues no mola. Tenemos que escribir nombres de test que nos indiquen que hace el test algo así como show_error_when_user_not_logged()

Conclusiones

En definitiva, creo que todo esto del naming, no es más que iterar. Sé que a la primera no voy a acertar pero poco a poco iré llegando a un consenso, a una serie de nombres que me hagan la vida más fácil.

Estrategias para escribir mejores test

Hace tiempo, odiaba escribir test, me resultaban una perdida de tiempo. Y si empezaba a escribirlos, rápidamente los dejaba de lado porque me resultaban lentos.

Y el problema era que no sabía como escribir tests. Ahora me encanta escribir test, es más, me siento un poco incómodo si no tengo unos pocos tests para ver si todo está funcionando bien (al menos el “happy-path”).

Voy a contarte algunos trucos que me ayudan a la hora de escribir test, ¿compartes tu también los tuyos?

Key Strategies For Ensuring Skillful Auto Repair Work

Seguir leyendo “Estrategias para escribir mejores test”

Haciendo debug con patitos de goma

¿En serio? ¿Cómo es posible que la mejor manera de hacer debug sea usando un patito de goma? Aunque visto así, pueda parecer un poco bizarro voy a contarte porqué hacer debug con un patito de goma es más efectivo de lo que parece. No es una técnica novedosa, los programadores más experimentados utilizan esta técnica para encontrar problemas en su código de una manera sencilla e intentar reducir su frustración cuando algo no termina de encajar del todo.

En realidad, está técnica viene explicada en el libro The Pragmatic Programer, voy a intentar explicar que es exactamente eso del patito de goma y porqué creo que es una táctica super efectiva.8164695884_25b5c6744d_z

Seguir leyendo “Haciendo debug con patitos de goma”

mi experiencia con el curso y la certificación de “Professional Scrum Master I”

Hace un tiempo asistí al curso de Professional Scrum Master impartido por Jerónimo Palacios. Mi idea, en un principio era mejorar mi conocimiento sobre Scrum y afianzar ese conocimiento presentándome al examen de certificación Profesional Scrum Master I.

Aquí me gustaría contar como fue todo, como preparé el curso y la certificación y algunos consejos para el examen. Resumiendo mucho: el curso estuvo genial, aprendí un montón y me sirvió como punto de partida para estudiar a fondo la guía de Scrum. Ese conocimiento sobre Scrum, sus artefactos, roles y ceremonias, me sirvió para poder superar un examen tipo test en inglés con multi-respuesta, en el que hay 80 preguntas y hay que sacar más de un 85% de acierto, todo ello en menos de 60 minutos.

SONY DSC

Seguir leyendo “mi experiencia con el curso y la certificación de “Professional Scrum Master I””

Como montar un SSD en MacBookPro y como instalarlo todo automaticamente con ansible

Ya llevaba tiempo dándole vueltas a dar un poco de cariño a mi MacBook Pro (13 pulgadas, finales de 2011). Así que hace poco decidí instalar un SSD, junto con una memoria RAM de 8G. ¿Como hice todo esto?

La idea que tenía era sustituir el disco duro que trae el Mac por uno SSD, y dejar el CD en su sitio.

Compras

Seguir leyendo “Como montar un SSD en MacBookPro y como instalarlo todo automaticamente con ansible”