Un día normal, un bug cualquiera

Después de haber arreglado más o menos 1000 bugs en mi carrera como programador (de los que más o menos 700 los había cometido yo), creo que tengo una visión más o menos sencilla de como deberíamos escribir un ticket para que ayudemos lo máximo posible al programador de soporte. Así esa persona no tendrá que devanarse los sesos en entender que es lo que parece está ocurriendo

4885869609_136a774d74_z
Recklinghausen Herten – Wasserschloss Herten 03

Ejemplos como los siguientes son de lo más comunes cuando estamos haciendo soporte de usuarios:

– El formulario está fallando
– ¿Qué formulario? ¿Cuál es la URL?¿Qué es más o menos lo que falla?¿Qué estabas haciendo, cuéntame los pasos? ¿Con qué navegador?¿Puedes pasarme una captura de pantalla?…

– El informe que me descargo está en mal
– ¿Qué formulario? ¿Cuál es la URL?¿Qué es más o menos lo que falla?¿Qué estabas haciendo, cuéntame los pasos? ¿Con qué navegador?¿Puedes pasarme una captura de pantalla?…

La primera pregunta que tenemos que hacernos ante un problema así es: ¿Cuál es el comportamiento normal? ¿Que hacía eso que “parece” que está fallando? ¿Tenemos un sitio para trackear las subidas y ver si se hemos subido algo últimamente?

Seguir leyendo “Un día normal, un bug cualquiera”

Anuncios

Algunos mitos sobre el testing

Ultimamente casi todo el mundo habla de testear, de hacer refactoring, de mejorar,.. parece que intentar hacer las cosas bien se está poniendo de moda. Y eso mola.

Hoy me gustaría hablar sobre mi experiencia haciendo testing unitario y sobre los mitos que creo que hay detrás de todo esto de los tests. Eso sí, esto son opiniones personales basadas en mi experiencia por lo que no pueden traducirse a todos los escenarios, por eso me encantaría conocer tu visión en los comentarios.

4905093544_8d1324d7f2_z
J. A. Alcaide

Vamos a por los mitos:

Seguir leyendo “Algunos mitos sobre el testing”

¿Qué hacemos para mejorar como equipo?

Soy una persona curiosa, me gusta aprender cosas nuevas, leer, investigar nuevas tecnologías, encontrar maneras de mejorar,… pero eso no puedo hacerlo solo. Necesito tener cerca información: buscar en Internet, tener a mano a compañeros y colegas que saben mucho más que yo a los que poder preguntar,… en definitiva, necesito un ecosistema que funcione para poder seguir mejorando.

Seguir leyendo “¿Qué hacemos para mejorar como equipo?”

Aprendiendo, distintas maneras de aprender

Me considero una persona curiosa, me gusta aprender nuevas herramientas, nuevos métodos de trabajo, conocer frameworks, patrones,… parece sencillo. En Internet hay cantidad de información sólo tenemos que navegar y consumir. Pero no es tan fácil, es tal la cantidad de información que es muy difícil

4364377924_cd66150c45_z
Ted Major

mantener encontrar buenos recursos, mantener el foco y sacarle provecho al material. Vamos a intentar revisar los distintos métodos que hay para aprender sobre un framework, librería, una metodología…

 

Seguir leyendo “Aprendiendo, distintas maneras de aprender”

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.