Code reviews: comunicación, comentarios y asertividad

Revisar el código de otros compañeros antes de una pull request o antes de pushear es una práctica bastante extendida. Pero ¿cómo hacerlo de manera efectiva? Hace tiempo escribí un post sobre “Cómo llevar a cabo una code review y qué puntos tener en cuenta “ pero después de la “Software Crafter Madrid” me puse a buscar información sobre como mejorar la comunicacióne como intentar disminuir la fricción en las code reviews.

La idea de este post no es escribir en piedra una serie de normas, sino comentar una serie de trucos que a mi han funcionado y por eso me gustaría que tú te animaras a contarme los tuyos. Abajo dejo una serie de referencias

4026722749_18a80f2690_z
Jaguar E-Type 4-2 – Chris Devers

Sigue leyendo “Code reviews: comunicación, comentarios y asertividad”

Algunos trucos para escribir código

Muchas veces se nos llena la boca hablando de los principios SOLID y de que tenemos que escribir mejor código, pero ¿qué significa eso de escribir mejor código? En realidad yo no lo sé, pero en este post voy a contar como intento acercarme a los principios SOLID y al Clean Code en mi día a día como desarrollador PHP.

 

crowd music musician street performer
Photo by Negative Space on Pexels.com

A rasgos generales intento usar Object Calisthenic unido a trabajar la legibilidad del código y que este se lea como prosa. Y algo muy importante, estas indicaciones no debes seguirlas estrictamente, son solo una serie de normas que sigo a veces (repito a veces). Son unas pequeñas pautas, nada más así que si las aplicas no seas demasiado rígido.

Utiliza variables que puedas pronunciar

La idea es que puedas pronunciar el nombre de las variables, funciones y clases. No importa que el nombre quede un poco largo, es mejor saber de qué trata una variable con solo leerla, que tener que intuir el acrónimo.

Mal

$ymdstr = (new \DateTime())->format('y-m-d');

Bien

$currentDate = (new \DateTime())->format('y-m-d');

 

Utiliza constantes para minimizar los números mágicos

La idea es que todo se lea como prosa, así que encontrarse con un 5 o un 23 no mola.

$result = $serializer->serialize($data, 448);

¿Qué significa el 448? Creo que queda mejor algo así:

$json = $serializer->serialize($data, JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT | JSON_UNESCAPED_UNICODE);

Esto mismo puede aplicarse dentro de una clase a por ejemplo los estados de un usuario.

class User
{
   const ACCESS_READ = 1;
   const ACCESS_UPDATE = 4;
   const ACCESS_DELETE = 8;
}

if ($user->access && User::ACCESS_UPDATE) {

   // do edit ...
}

Utiliza variables explicativas

¿Qué hace este trozo de código?

$str = 'One Infinite Loop, Cupertino 95014';

preg_match('/^[^,]+,\s*(.+?)\s*(\d{5})$/', $str, $matches);

save($matches[1], $matches[2]);

Seguramente en 1 minuto seas capaz de decirmelo, pero imagina que estas debugeando porque quieres resolver un bug y te encuentras con esto. Tardarás un minuto en saber que hace y lo peor de todo es que quizás pierdas el foco de lo que estabas haciendo.

Por ello creo que lo mejor es utilizar variables que expliquen que es lo que estás haciendo, algo así:

$address = 'One Infinite Loop, Cupertino 95014';
$cityZipCodeRegex = '/^[^,]+,\s*(?<city>.+?)\s*(?<zipCode>\d{5})$/';
preg_match($cityZipCodeRegex, $address, $matches);

saveCityZipCode($matches['city'], $matches['zipCode']);

¿Se entiende algo mejor?

Encapsula condicionales

Cuando estamos leyendo código, llevamos encima una mochila de carga cognitiva sobre que es lo que hace el código, el contexto de la aplicación, las variables… por eso lo que siempre intento es minimizar esa carga y hacer que con solo leer una variable o una condición sepa que es lo que hace. Por ejemplo, normalmente evito hacer cosas como esta:

if ($article->state === 'published') {
   // ...
}

Lo que hago es intentar dar contexto y sobre todo en los if crear funciones booleanas que para que sea mucho más fácil responder a la pregunta del if que evaluar la condición. Me explico:

if ($article->isPublished()) {
   // ...
}

La función isPublished siempre devolverá un booleano, así es más facil seguir la traza del código.

Evita los else y apuesta por los “early returns”

La idea es que no haya demasiados else y que los casos base se resuelvan los más pronto posible.

Vamos a poner el ejemplo del cálculo de fibonacci:

function fibonacci(int $n)
{
   if ($n < 50) {
       if ($n !== 0) {
           if ($n !== 1) {
               return fibonacci($n - 1) + fibonacci($n - 2);
           } else {
               return 1;
           }
       } else {
           return 0;
       }
   } else {
       return 'Not supported';
   }
}

Pero ¿y si intentamos primero los casos base/excepciones y luego el flujo normal):

function fibonacci(int $n): int
{
   if ($n === 0 || $n === 1) {
       return $n;
   }

   if ($n > 50) {
       throw new \Exception('Not supported');
   }

   return fibonacci($n - 1) + fibonacci($n - 2);

}

Demasiado contexto

Esto es algo que me pasa siempre, intento dar buenos nombre y al final lo que acaba pasando es que me paso de frenada y las variables tienen demasiado contexto. Algo así tampoco es bueno.

class Car
{
   public $carMake;
   public $carModel;
   public $carColor;
 
  //...
}

Hay que mantener el equilibrio entre el gym y el ñam

Evita los nombres genéricos

En la búsqueda del equilibrio, también tenemos que tener en cuenta lo malos amigos que son los nombres genéricos. Nombres como Manager, Pool, Handle… funcionan en cualquier contexto, da igual que sea un ERP que una central nuclear en los dos habrá un Manager o un Handler. Así que lo mejor es que tengas cuidado con su uso. Estamos en lo de siempre el equilibrio entre el gym y el ñam.

class Email
{
   public function handle(): void
   {
       mail($this->to, $this->subject, $this->body);
   }
}

$message = new Email(...);

$message->handle();

¿Qué hace handle en este contexto?, queda un poco rato. Lo ideal sería cambiarlo por send, así le damos contexto a la clase Email. Ese contexto surge porque la clase Email realiza acciones “send”.

No utilizar flags

Las funciones no cuestan dinero, así que no te agobies cuando tengas que crear una nueva. Es cierto que reutilizar está bien, seguir el principio de única responsabilidad y todo eso. Pero no debemos perder la cabeza con estas cosas, así que una de las alertas para saber que has perdido un poco el foco es ver funciones con flags como esta:

function createFile(string $name, bool $temp = false): void
{
   if ($temp) {
       touch('./temp/'.$name);
   } else {
       touch($name);
   }
}

Creo que se podrían crear 2 funciones:

function createFile(string $name): void
{
   touch($name);
}

function createTempFile(string $name): void
{
   touch('./temp/'.$name);
}

Proximidad

Declaro las variables tan cerca de su uso como sea posible. Algo así queda un poco raro, sobre todo a la hora de refactorizar y mover cosas de sitio se hace complicado con una estructura como esta:

function hi() 
{
    $a = $this->getA(),
    $b = $this->getB(),
    $c = $this->getC(),
    $d = $this->getD();

    $this->doSomething($b);
    $this->doAnotherThing($a);
    $this->doOtherStuff($c);
    $this->finishUp($d);
}

Mi idea es intentar escribir algo así:

function hi() {
  $b = $this->getB();
  $this->doSomething($b);

  $a = $this->getA();
  $this->doAnotherThing($a);

  $c = $this->getC();
  $this->doOtherStuff($c);

  $d = $this->getD();
  $this->finishUp($d);
}

Ahora queda mucho más claro por lo que lo ideal es usar una variable justo después de su declaración.

Normalmente no es tan simple como este ejemplo, ya que hay dependencias y tal, pero la idea general es esta.

Resumen

Si tuviese resumir que es lo que intento o hacia donde empujo mis soluciones cuando estoy escribiendo código es hacia:

  • Usar poca indentacion: eso hace que el código sea más entendible,
  • Evito utilizar else para conseguir un flujo lineal del programa.
  • Early return siempre que puedo: hacer todas las comprobaciones al principio para intentar ejecutar más código del necesario.
  • Que el código se lea bien: variables con buenos nombres, sin abreviaturas excesivas y con el contexto adecuado.
  • Explaining variables: En las guardas de los if intento que siempre haya una función o variable que empiece por “is” así sé si es true o false.
  • Paciencia: poner un buen nombre no se consigue fácilmente, muchas veces hay que cambiarlo más de 1 o 2 veces.
  • Equilibrio: nos pagan por solucionar problemas y por hacer buen código. Así que no hay que agobiarse, quizás en una primera pasada tomemos algún que otro atajo. No es malo, solo hay que llegar a ese punto en el que escribimos buen código sin perder la cabeza por el código bien escrito.

Este artículo se basa en este repositorio donde encontrarás muchos más ejemplos.

consejos y trucos de composer PHP

¿Conoces composer? Seguro que ya lo utilizas desde hace tiempo en tus proyectos de PHP. Composer es un manejador de dependencias y paquetes en PHP, si quieres empezar, hace ya bastante tiempo que hablé de como sacarle partido a composer y de cómo hacer una libreria utilizando composer. Hoy voy a dar una lista de consejos y trucos.

Partimos de que ya utilizas composer, sabes sus comandos básicos y quieres subir al siguiente nivel. Quieres saber qué más puedes hacer, quieres conocer la diferencia entre ~ y ^, quieres saber qué hacer con el composer.lock,…

Lo primero, lee la documentación. Es el mejor consejo que puedo darte, en la documentación de composer está todo y seguro que hay otras muchas funcionalidades que pueden serte útiles en tu proyecto.Sigue leyendo “consejos y trucos de composer PHP”

Retrospectiva y Objetivos 2018

Es hora de reflexionar sobre todo este año y si tuviese que escribir una frase sería “cambios, vida y felicidad”. Porque empecé el año siendo padre de la pequeña Aitana, me certifiqué como “Profesional Scrum Master”, di un par de charlas en Meetups, fui a la TarugoConf y a Codemotion. Justo antes de asistir a la TarugoConf mi familia y yo Madrid y yo me despedía del gran equipo de coches.com. Volvimos a Sevilla, y junto al gran equipo de QAShops sigo aprendiendo, mejorando y disfrutando de cada día. Aún así incluso este año me dio tiempo a visitar Budapest, a perderme por Sevilla una vez más y sobre todo a disfrutar cada momento junto a mi familia.

16255888356_f278413370_z

Sigue leyendo “Retrospectiva y Objetivos 2018”

De vuelta al mundo real

Llevo varias semanas sin actualizar el blog y no por falta de ganas, sino porque he estado disfrutando de experiencias increíbles que me gustaría contaros hoy.

Desde que llegué a Sevilla ha sido un no parar de hacer cosas, en estas ultimas 2 semanas facilité una kata en PHPSevilla, estuve echando una mano de mentor en el Sevilla Startup Weekend y para terminar la semana cogí un AVE a Madrid para ir a la Codemotion.

32007811964_d46496180e_z.jpg

Pero es que antes de eso estuve en la TarugoConf (espectacular), es un eventazo que te llena de energía y te da pie para hablar con la flor y nata del mundo startupil. Entre tanto me dio tiempo a establecerme en Sevilla, encontrar piso, mudarme y todo ese rollo. Y lo más importante: sigo teniendo una hija que crece cada día más rápido y con la que disfruto.

TarugoConf

Ya lo he dicho antes, es un eventazo donde pude conocer a un montón de gente que sigo en twitter, la verdad es que me encantó en todos los sentidos. Candela, David Bonilla & Co. hacen un trabajo espectacular. Aquí os dejo el post del postmortem http://www.bonillaware.com/postmortem-tarugo17

Kata en PHPSevilla

Cuando estuve en Junio con los chicos de PHPSevilla hablando sobre refactoring, me sentí como en casa. Así que a mi vuelta a Sevilla me propusieron hacer una pequeña kata para haciendo pair programing, aprender TDD.

El meetup comenzó con una pequeña introducción a el ciclo de TDD: Red – Green – Refactoring. Haciendo hincapié en que es muy complicado cambiar la mentalidad de escribir primero los tests y por ello hay que ir pasito a pasito (baby steps). En la charla comenté que bajo mi punto de vista, la mejor manera de empezar con TDD es que tenemos que ser, sobre todo al principio, muy estrictos siguiendo las reglas:

  • Hacer un test
  • Comprobar que falla
  • Hacer el código mínimo para que funcione
  • Refactorizar si es necesario
  • Volver al principio

Después de la pequeña charla el reto consistió en ponernos por parejas y resolver un pequeño problema, en este caso FizzBuzz. Estuve echando una mano a los compañeros que andaban por allí, intentando resolver dudas y haciendo que todos pasaramos un buen rato La verdad que a mi como facilitador me gustó mucho la experiencia, espero que los asistentes también. Con el pequeño ejercicio de FizzBuzz, pudimos demostrar de primera mano que seguir las reglas de arriba no es tan sencillo como parece.

Desde aquí dar las gracias a los organizadores de PHPSevilla por fomentar eventos tan molones, a los sponsors por cedernos el local y sobre todo a todas las personas que participaron.

Sevilla Startup Weekend

Se trata de un evento emprendedor que se celebró desde el viernes 17 de Noviembre hasta el domingo, en el que los participantes trabajan durante más de 54 horas para convertir sus ideas de negocio en una ‘startup’.

A decir verdad, cuando me propusieron ser mentor me pilló un poco de sorpresa. Además no conocía a nadie de SevillaUP (las maravillosas personas detrás del evento), pero eso no me quitó las ganas de echar una mano en lo que pudiese durante el fin de semana.

El evento tuvo lugar en el “Club Antares” un sitio muy chulo donde había muchísima gente con ganas de pasar un finde aprendiendo y disfrutando. Como comenté al principio no conocía a nadie, pero el buen rollo entre mentores, organización y participantes hizo que nos hiciésemos piña y que todo saliese genial.

Me sorprendió mucho la cantidad de personas de todas las edades, había chavalada de 16-20 años hasta gente con mucha experiencia que tenía el gusanillo de pasar el finde validando ideas de negocio. Es impresionante lo mucho que me aportó el evento, la cantidad de cosas que aprendí y la gente tan interesante con la que charle. Impresionante tambien el cariño que le ponen las chicas y chicos de SevillaUp a todo lo que hacen es tremendo. Las ganas que le ponen los participantes para estar todo el finde trabajando. Y qué decir del resto de mentores, es genial que gente tan grande saque un hueco para venir el finde y poder aprender mucho de ellos. Me he sentido super pequeñito al lado de personas tan grandes y con tanto que aportar.

Codemotion

Coger el primer AVE de la mañana no es nada fácil, hay que luchar contra las ganas de quedarse calentito en la cama. Pero la ocasión lo merece: Codemotion. Para el que no lo conozca, es un evento con más de 140 charlas y talleres donde van (o vamos) más de 2000 asistentes con ganas de aprender y sobre Machine Learning, Deep Learning, Microservicios, Cloud Computing, Contenedores, Desarrollo software,…

Me encantó el evento, no solo porque las charlas a las que fuí estuvieron geniales, sino porque pude reencontrarme con antiguos compañeros, antiguos jefes, colegas de profesión y encima me dió tiempo a desvirtualizar a unas cuantas personas solo conocía por Twitter o por los cursos online de Refactoring. Una pena no haber podido desvirtualizar a más gente.

Las charlas que más me gustaron:

  • How to create a healthy and productive environment. Felix contó unos cuantos tips sobre como tener una cultura de equipo sana, competitiva y que haga crecer al equipo.

  • ¿Tienes un #bug? Tus tests unitarios no están bien planteadosAunque el ponente dijo que que era para beginners fue una charla muy bien contada y con las ideas muy claras de como afrontar el testing, mocking.

  • Las reglas que hay que romper para que tu equipo de desarrollo sea el más rápido, de Javier Abadía. Me pareció una charla muy divertida, muy bien contada y con muchos buenos consejos. Donde el mensaje estaba en que lo importante es dar soluciones que aporten valor al negocio y a los usuarios no en disputas de primer mundo (espacios vs. tabuladores, codigo acoplado, command buses/event sourcing,…)

  • El informático de David Bonilla. Fue un cierre de Codemotion brutal en mi opinión. La charla (aunque con un ritmo un lento) dejó un monton de preguntas en el aire y sirvió para irnos a casa con la conciencia removida. La verdad es que quiero volver a escuchar esta charla. Menos mal que el equipo de Autentia estuvo a tope grabando las charlas.

Conclusiones

Me gustaría escribir más, pero hasta ahora mi manera de escribir era abrir un monton de pestañas en Chrome, ponerme a picar código e ir escribiendo en sublime lo que iba haciendo. Creo que para seguir escribiendo de manera regular tengo que darle una al proceso, sobre todo porque ahora con la pequeña no tengo tanto tiempo de seguido.

Así que he empezado a utilizar google keep para apuntar las ideas, posts, referencias. Una vez a la semana (más o menos) les pongo un poco de orden y las categorizo en Trello. Cuando creo que tengo material suficiente creo un doc en Google Drive y empiezo a darle forma. Espero que con esta forma me de tiempo porque material tengo un bastante.

Screen Shot 2017-12-12 at 19.00.45.png

Por eso nos vemos en el próximo post. ¡Espero que sea pronto!

Por cierto, ahora que veis las temáticas, ¿os atraen? ¿os gustaría que profundizase sobre algo que no he tocado? ¿alguna idea?

 

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?

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

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:

Sigue 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.

Sigue 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…

 

Sigue 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.

Sigue leyendo “Aprendiendo en PHPSevilla, experiencia de mi primera charla sobre Refactoring en PHP”