Jesús L.C. – Apuntes de un aprendiz
Problem solver, product developer, eternal learner. Refactoring, TDD, CI/CD pipeline, agile
Hace unos días tuve la oportunidad de ser speaker en CommitConf donde estuve hablando sobre «La pirámide del testing». Esta charla surgió a partir del articulo del mismo nombre «La pirámide del testing» donde comentábamos distintas maneras de afrontar el testing en un proyecto software. Desde aquí solo puedo dar las gracias a la organización … Continúa leyendo La piramide del testing en la CommitConf 2024
Los tests son importantes, ya hemos dado la turra en el blog bastantes veces: desde cómo organizar los test, estrategias para escribir mejores tests, o incluso hemos hablado «la jerga del testing», pero un tema que siempre hemos dado por sentado es la pirámide de test. La pirámide de test o pirámide de Cohn, es un framework que … Continúa leyendo ¿La piramide del testing?
Las feature flag también conocidas como feature toggles son una técnica que permite cambiar el comportamiento del sistema sin cambiar el código. Básicamente estos «interruptores/semáforos» nos permiten habilitar una funcionalidad en tiempo de ejecución sin tener que volver a desplegar el código. Es un concepto muy simple, tan simple como un if pero con unas … Continúa leyendo Cómo cambio mi vida desde que uso feature flags
Los tests son importantes, eso ya lo sabemos y los gurús de Twitter no dejan de repetirlo: «El testing es una práctica fundamental para garantizar la calidad»… pero ¿cómo podemos sacarle más partido a los tests? Con los tests podeos detectar defectos y lo más importante es que hacemos el software fácil de modificar en el futuro, básicamente los tests nos dan confianza en el sistema. Para llegar a esa confianza tenemos distintas estrategias, como la pirámide de los test: los tests deben organizarse en una pirámide con tres capas: tests unitarios, tests de integración y tests de aceptación… pero ¿hay otras alternativas? y de manera física, como donde ponemos esos tests ¿en que carpeta iría este,.. ¿cómo organizar los tests? Además también tenemos los tests de regresión, los test de carga,.. Como podemos ver el tema del testing es muy extenso y podemos hablar de muchas cosas. Incluso en el blog ya ha hemos escrito sobre estrategias para escribir mejores tests, sobre «la jerga del testing», no solo una sino dos veces) y hace ya bastante tiempo hablamos sobre los mitos del testing(como que el software con test esta libre de bugs). Así que hoy vamos a intentar organizar un poco todo esto.
Vamos a dejar claro que entendemos por tests. Los tests van a ser ficheros que contienen código que que sirve para evaluar o verificar el comportamiento de una parte del sistema. Normalmente utilizamos frameworks como phpunit para que nos ayuden con este propósito. Por otro lado también tenemos ficheros de configuración para indicar como ejecutar los tests. Por último también podríamos tener ficheros de soporte, como por ejemplo abstract tests clases, helpers, fixtures, que podemos organizar en diferentes archivos.
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:
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?»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
¿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.
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?»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»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
¿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.
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»
Jesús L.C. - Apuntes de un aprendiz 