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?”
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
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…
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.
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.
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.
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”
$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.
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.
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:
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.
¿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.
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()
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.
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?
¿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.
