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»
Anuncio publicitario

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»

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.

Continúa leyendo «Aprendiendo en PHPSevilla, experiencia de mi primera charla sobre Refactoring en PHP»

Haciendo testing unitario al 100

Haciendo testing unitario al 100%. Hace unos días estuvimos hablando de como refactorizar controladores para separar responsabilidades. Ahora llega la hora de dar un paso más y testear unitariamente las clases que creamos.

La idea detrás de este post es que modifiquemos una clase ya construida y funcional, llenarla de tests y refactorizarla para que los test solo testeemos una clase y no necesiten más que phpunit, ni base de datos ni más clases de las necesarias.

Continúa leyendo «Haciendo testing unitario al 100»

Refactorizando el cliente de “Cat API” – Parte 3 –

Esto es una traducción libre de Refactoring the Cat API client – Part III

En la primera y segunda parte hemos estado trabajando en separar las preocupaciones que teníamos al principio combinadas en una sola función.

Los principales «personajes» en el escenario ya han sido identificados: un httpClient y una caché, utilizadas por diferentes implentaciones de CatApi para poder testar y realizar un cliente para The Cat Api

Continúa leyendo «Refactorizando el cliente de “Cat API” – Parte 3 –»

Refactorizando el cliente de «Cat API» – Parte 2

Esto es una traducción libre de Refactoring the Cat API client – Part II

El mundo un sitio seguro

Cuando estas ejecutando test unitarios, no quieres que el resto del mundo este involucrado en tus tests. Ejecutar consultas en bases de datos reales, hacer peticiones HTPP, escribir en ficheros, nada de esto es deseable: harán que tus tests sean lentos e impredecibles. Si el servidor en el que estas haciendo tu petición está caído, o responde de manera inesperada tus test unitarios fallarán por razones equivocadas. Un test unitario solo debería fallar si tu código no hace lo que se supone que debería hacer.

Como hemos visto en el post anterior de la serie, tanto la clase CachedCatApi como RealCatApi de alguna manera dependen del mundo. La primera escribe ficheros en el sistema de ficheros, la segunda hace peticiones HTTP. Además, la creación de fichero y las peticiones HTTP son cosas de bastante bajo nivel, para lo cual las clases no utilizan las mejores herramientas disponibles. De la misma manera, un montón de casos límite no están siendo tenidos en cuenta.

Continúa leyendo «Refactorizando el cliente de «Cat API» – Parte 2″

Refactorizando el cliente de «Cat API» – Parte 1

Esta es una traducción libre de Refactoring the Cat API client – Part I

Mattias Noback tenía la idea de hacer una serie de videos sobre «Principles of Package Design book» pero finalmente en vez de videos hizo una serie de post con el material que tenía pensado presentar en los videos.

Para empezar esta es una pequeña pieza de código:

class CatApi
{
    public function getRandomImage()
    {
        if (!file_exists(__DIR__ . '/../../cache/random') 
            || time() - filemtime(__DIR__ . '/../../cache/random') > 3) {
            $responseXml = @file_get_contents(
                'http://thecatapi.com/api/images/get?format=xml&type=jpg'
            );
            if (!$responseXml) {
                // the cat API is down or something
                return 'http://cdn.my-cool-website.com/default.jpg';
            }

            $responseElement = new \SimpleXMLElement($responseXml);

            file_put_contents(
                __DIR__ . '/../../cache/random',
                (string)$responseElement->data->images[0]->image->url
            );

            return (string)$responseElement->data->images[0]->image->url;
        } else {
            return file_get_contents(__DIR__ . '/../../cache/random');
        }
    }
}

Como se puede adivinar, la función getRandomImage devuelve una URL de la imagen aleatoria (y que existe) de Cat API. Cuando llamamos a la función en dentro de una ventana de tiempo de 3 segundos, se devuelve la misma URL para que el servicio sea más rápido, así como para no abusar de Cat API.

Continúa leyendo «Refactorizando el cliente de «Cat API» – Parte 1″

Refactorizando legacy code en PHP Parte 9 – Los últimos toques

Ya casi estamos acabando con la refactorización, parece mentira cuando empezamos con un solo archivo PHP, ahora tenemos clases, interfaces e incluso inversión de dependencias. Somos capaces de modificar algo sin miedo porque tenemos tests que nos indican si estamos cometiendo errores. Además podemos ampliar la funcionalidad de nuestra aplicación de una manera más o menos sencilla.

En este tutorial vamos a atacar a la “clase” GameRunner. Bueno a los métodos del archivo GameRunner para convertirlos en una clase para más adelante terminar de refactorizar los métodos que nos quedan de la clase Game.

Llegando a ser orientado a objetos

A pesar de que tenemos la mayor parte de nuestro código orientado a objetos, algunas funciones están solas en un archivo. Así que el objetivo de este post es convertir esos procedimientos en algo más orientado a objetos.

Continúa leyendo «Refactorizando legacy code en PHP Parte 9 – Los últimos toques»

Refactorizando legacy code en PHP Parte 8 – Inyección de dependencias

Volvemos otra vez a la carga refactorizando nuestra aplicación php legacy. Esta es la serie de posts más larga que he hecho hasta el momento, pero creo que el tema lo merece.

Esta entrega empezaremos ha plantear la arquitectura de la aplicación, o al menos una separación lógica de clases que irá evolucionando. Nuestra arquitectura debe centrarse en la lógica de negocio. Alrededor de esta tendremos varios módulos “auxiliares” que tienen diversos fines.

Por ejemplo conectar al usuario con la aplicación, en nuestro caso será la linea de comandos. Por otro lado tenemos la persistencia, que en nuestro caso no nos afecta ya que no utilizamos nada de este tipo. También tenemos las factorías y constructores y por ultimo están las clases que representan la entrada al sistema. En nuestra aplicación de Trivial podría considerarse la clase GameRunner de este tipo.

Continúa leyendo «Refactorizando legacy code en PHP Parte 8 – Inyección de dependencias»