Publicado el

¿Por qué el naming es importante?

La mayor parte de mi tiempo cuando programo la invierto en leer código, por lo que la legibilidad del código es una parte fundamental para que mi yo del futuro (y el resto de compis que trabajan conmigo) puedan entenderlo, mantenerlo y por supuesto mejorarlo en el futuro. Por tanto el naming de variables, funciones, clases,… es uno de los aspectos más importantes a la hora de escribir software.

En el blog ya hemos hablando de este tema hace tiempo en post «Clean Code» sin escribir una linea de código donde comentábamos que la importancia del naming, los mensajes de commit, el code style,… de manera muy concisa y breve. Por otro lado en Mejorando el naming de nuestro código estuvimos escribiendo sobre el proceso del naming: (Missing, Nonsense, Honest,Honest and Complete,…) y los pasos a seguir para intentar dar buenos nombres:

  • 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»

    Proceso para crear buenos nombres extraído del post «Mejorando el naming de nuestro código»

En el post de hoy vamos a ir al grano y vamos a dar ejemplos de que es para mi un mal nombre y como podemos mejorarlo.

Continúa leyendo «¿Por qué el naming es importante?»
Anuncio publicitario
Publicado el

Más allá del remoto: rompiendo el hielo con icebreakers

Con todo esto del trabajo en remoto estamos todos en casa o yendo a la oficina solo unos poco días. Así que de vez en cuando es necesario que todo el equipo se junte para trabajar juntos, vernos las caras y en muchos casos conocernos más allá de una pantalla y una webcam. Todos sabemos que para crear producto sofware la vertiente humana es importante. Poder conocer a las personas con las que trabajas más allá de las code reviews, las daily meetings y reuniones varias es algo que creo que aporta mucho al equipo. Continúa leyendo Más allá del remoto: rompiendo el hielo con icebreakers

Publicado el

¿De verdad tenemos que hacer code review?

¿Todo tiene que ir en code review? ¿Hay que hacer la code review antes?¿por qué no la hacemos después de mergear? Si ya hacemos pair/mob programming ¿tiene sentido también una code review? Ya hemos hablado antes de como hacer code reviews con fundamento, de que las code reviews son algo más que código: son comunicación entre personas. También hemos visto cómo llevar a cabo una code review y qué puntos tener en cuenta. Las code reviews son un «estandar de mercado» todo el mundo las hace porque X. Dependiendo de nuestro contexto, de cada equipo, de cada empresa,… puede que haya otras prácticas ténicas que mejoren nuestra productividad y el flujo de valor hacia el usuario.

Partamos de la base de que esto que pongo aquí es mi opinión este post se basa en mi «cámara de eco» ( experiencia trabajando, opiniones compartidas, libros, artículos y recursos que he ido viendo,…) La idea de este post es que reflexionemos sobre las prácticas que tenemos en nuestro equipo y de que vez en cuando nos preguntémos el porqué de esas prácticas que utilizamos y si siguen teniendo sentido en el contexto actual.

¿Para qué sirve una code review?

Hablemos de que es lo que aporta una code review. En la industria, las code review tienen 2 objetivos principales: compartir conocimiento y mejorar la calidad del código.

Continúa leyendo «¿De verdad tenemos que hacer code review?»
Publicado el

Haciendo code reviews con fundamento

Aunque cada día veo que más gente hace pair programming, mob programming,… lo habitual es hacer pull request/merge request y tener que revisar el código (aka. code review) de los compañeros antes de integrarlo (lo de antes podemos discutirlo en otro post) en la rama principal. En este post vamos a tratar algunos puntos sobre cómo hacer code reviews con fundamento, sin opiniones, hablando de code smell.

Normalmente las pull request son una práctica que causa bastante fricción y a la que en mi opinión no le dedicamos la importancia que tienen: si hemos decidido hacer pull request antes de integrar, estas deberían ser el objetivo prioritario. El código de esta pull request/merge request está muy cerca de aportar valor. ¡Y qué no lo está haciendo porque no le estamos poniendo el cariño suficiente!

Hace tiempo ya estuvimos comentando en el blog Cómo llevar a cabo una code review y qué puntos tener en cuenta y que la code review involucra a lo más importante personas, por lo que la comunicación, los comentarios y la asertividad son importantes de cara a que podamos aportar feedback de calidad.

Para otro post dejaremos listar los que son en mi opinión los problemas principales de una code review, hoy, vamos a hablar un poco de cómo podemos mejorar nuestras code reviews como revisores. Vamos a partir de la base de que queremos aportar feedback accionable, de calidad y dejar de lado las opiniones y para ello nada mejor que conocer un poco más acerca de los code smells.

Continúa leyendo «Haciendo code reviews con fundamento»
Publicado el

Como escribir código difícil de mantener en PHP

Muchas veces se nos llena la boca hablando de Clean code, de hacer código limpio, de seguir los principios SOLID, pero escribir ¿cómo podemos escribir código difícil de mantener en PHP? ¿cómo hacer que todo a tu alrededor dependa de nosotros? Eso no parece sencillo, pero siguiendo los siguientes consejos podemos conseguir el famoso vendor lock-in y así volvernos una pieza indispensable de nuestra compañía.

Este post está hecho en tono irónico/sátira. No nos tomemos al pie de la letra el contenido

Photo by Lukas on Pexels.com
Continúa leyendo «Como escribir código difícil de mantener en PHP»
Publicado el

Automatizando para pensar en el problema y no en recordar comandos cuando programamos en PHP

¿Cuantas veces te ha pasado que hecho una pull request y aparecen 300 cambios porque el code style es distinto? ¿O qué nos ha faltado añadir un tipado en los parámetros de una función? ¿Cómo saber si tenemos alguna librería vulnerable? A mí estas cosas me han ocurrido más de una vez por eso intento tener todas estos temas automatizados, ya sea por medio de librerías, teniendo plantillas o atajos.

La idea que hay detrás de automatizar es tener un feedback loop lo más rápido posible y poder darnos cuenta de esos errores/mejoras cuanto antes. Quien me conoce sabe que más de una vez he contado la metáfora de la mochila: mientras estamos desarrollando llevamos una mochila con varios temas: la carga cognitiva intríniseca que hay en programar, ver ese trozo de código que habría que modificar, no perder el norte porque la idea es añadir X feature, los tests, el code style, si hay que añadir un caso nuevo a los tests, si los test son legibles, si el código lo entenderé dentro de 2 semanas, como afecta ese cambio al resto de la aplicación… tenemos que mantener la mochila lo más «vacía» posible para de verdad centrarnos en lo importante.

Photo by Tim Samuel on Pexels.com

Por todo eso, en este post vamos a contar una serie de librerías, plantillas,etch para automatizar todo lo posible un pryecto en PHP y hacer que podamos dedicarle más tiempo a pensar y menos a recordar cómo era ese comando que tienes que lanzar o si la llave iba en la misma linea o en la siguiente. Vamos a hablar solo de librerías y de nuestro entorno local, pero debemos de tener en cuenta que todo lo que vamos a contar podríamos llevarlo a nuestro pipeline de Integración Continua con tan solo rellenar un YML

Continúa leyendo «Automatizando para pensar en el problema y no en recordar comandos cuando programamos en PHP»
Publicado el

Anti-patrones de tests, no cometas los mismos errores que yo

Te llega un email, es otro ticket de ese envío de notificaciones que hiciste hace tiempo, la solución que hiciste tiene otro bug,.. ¿te suena? O abrir un pedazo de código, empezar a leerlo y que te entren sudores fríos porque no entiendes nada o porque lo que vemos allí no quieres tocarlo ni con un palo… y lo peor es que haces un git blame y eres tu mismo el que escribiste eso en un «día de inspiración». Quizás esos pedazos de código puedan ser un buen ejemplo de anti-patrón. Un anti-patrón es una serie de técnicas que nos conducen a una mala solución para un problema. Lo mejor que puedes hacer con los anti-patrones es conocerlos para así puedas evitarlos en el futuro.

Hoy me gustaría escribirte una pequeña recopilación de anti-patrones de tests. Hace unos años ya escribí sobre «patrones test utilizando PHPUnit» y sobre «patrones de test, mejorando la arquitectura en PHP» así que vamos allá.

Continúa leyendo «Anti-patrones de tests, no cometas los mismos errores que yo»
Publicado el

TDD no sirve para todo pero ayuda

Soy un fiel defensor de hacer tests y sobre todo de hacerlos antes de escribir una linea de código, pero no todo lo que hacemos tiene que estar hecho con TDD. Quizás el título sea un poco clickbait,.. en este post me gustaría que reflexionásemos sobre algunos aspectos a tener en cuenta de por qué Test Driven Development no es una bala de plata aunque ayuda mucho al diseño y de algunos temas interesantes alrededor del testing, refactoring y software.

"Cuando la única herramienta que tienes es un martillo, todo problema comienza a parecerse a un clavo".

No todo lo que hacemos tiene que estar hecho con TDD. ¡Pensar antes de escribir es mucho más importante! Por esta razón, estamos seguro de que es posible hacer buen software sin TDD. Aunque creo que hacer software sin TDD es más complicado porque no todo el mundo es capaz de pensar antes de escribir. Además a veces las «circunstancias» nos empujan a ir rápido, a tenerlo listo ya, o incluso a pensar (ilusos de nosotros) esto lo arreglamos más adelante. Del mismo modo, podemos llegar a un lugar oscuro si no nos planteamos a probar el software lo más pronto posible. Seguro que alguna vez nos ha pasado que llegamos a un una clase, servicio o feature que es difícil de probar. ¡eso sin duda es un «mal olor»! Quizás en el futuro ese mal olor acabe en algo podrido que y nos dé algún que otro dolor de cabeza. En cualquier caso cuando usamos TDD este nos provee de un proceso para analizar los problemas, para comprender qué es lo que está pasando, qué casos se nos pueden presentar, qué casos son excepcionales,….. además nos proporciona un arnés de seguridad para ir mejorando(refactor). Sin este proceso de TDD: hacer un test, comprobar que falla, hacer código para pasar el test y refactorizar, Lo qué tenemos es un proceso custom, donde cada miembro del equipo crea de manera distinta y por quizás lleguemos a situaciones en las que modificar un código se nos haga un poco cuesta arriba.

Continúa leyendo «TDD no sirve para todo pero ayuda»

Publicado el

Técnicas para mantener al legacy code bajo control

Somos desarrolladores de software, tenemos que leer código gran parte de nuestro día, tenemos que usar código legado y tenemos que mantenerlo, incluso añadir nuevas funcionalidades. ¿Cómo lo hacemos? ¿Cómo abordamos cambios en legacy code de manera eficiente? Pues no tengo ni idea, pero sí sé que si tengo una buena caja de herramientas cerca mi trabajo será más sencillo. Por eso en este post vamos a llenar nuestra caja de herramientas con algunas técnicas que nos ayudarán a trabajar un poco mejor con legacy code. No se trata de usarlas todas siempre, sino de tenerlas a mano para cuando nos hagan falta. Continúa leyendo Técnicas para mantener al legacy code bajo control

Publicado el

Modernizando aplicaciones PHP: antipatrones más comunes

A lo largo de mi carrera he tenido la oportunidad de «meter las narices» en unas cuantas aplicaciones… a algunas de ese aplicaciones podríamos llamarlas «legacy» en el sentido de que son aplicaciones que necesitan algo de «cariño». Recuerdo una pregunta en una ¿Y tu cómo te enfrentas a aplicaciones legacy? mi respuesta fue Con paciencia. Así que hoy escribiremos sobre antipatrones más comunes cuando nos enfrentamos a una aplicación legacy. Este artículo no vamos a reescribir todo en <el fancy framwork que sea>,sino que veremos como hacer nuestras aplicaciones un poco más mantenibles.

Si quieres profundizar más sobre el legacy este artículo titulado «Mi código en producción ya es legacy» de Fran Iglesias es genial.

Continúa leyendo «Modernizando aplicaciones PHP: antipatrones más comunes»