Developing Frogtek

El blog del Departamento de Tecnología

Revisión de código

Code Review

¿Revisar código?

¿Para qué?

¿Lo has probado?

Pues ya está ¿no?

Pues no. O al menos en Frogtek no nos vale. Y se agradece, la verdad. Veamos cómo y cuándo hacemos las revisiones de código.

Actualmente realizamos tres tipos de revisión de código:

  • Revisiones de código de las User Stories. Una vez terminadas y subidas al repositorio se revisan usando ReviewBoard, dando feedback, cuando sea necesario, a través de la herramienta. Dicha revisión se realiza dos veces. La primera por un programador y la segunda, por el tester antes de realizar el testing y verificación de la User Story.
  • Reuniones de revisión de código. Consisten en unas reuniones semanales en las cuales nos juntamos todos a ver, revisar, comentar… una funcionalidad nueva o un refactor especialmente delicado. Cualquier programador puede proponer código para ser revisado y nos animamos unos a los otros a ello.
  • Pair programinng de User Stories o parte de ellas. Aunque lo realizamos menos de lo deseado, lo usamos sobre todo cuando la funcionalidad que programar es complicada o propensa a errores. Nos ha dado muy buenos resultados siempre que lo hemos utilizado.

Solo llevamos alrededor de un año aplicando estás técnicas de manera exhaustiva, pero creo que las mejoras han sido sustanciales en la calidad de nuestro código y de nuestras habilidades.

Personalmente, lo que más me ha gustado es el conocimiento que se adquiere de toda la aplicación gracias a las revisiones. Ya no solo sabes lo que tú has hecho, sino gran parte de lo que el resto ha programado también.

Como nota final, un vídeo gracioso sobre Pair programing. En Inglés, lo siento.

4 Comentarios

  1. Lo mejor del pair programming, revisiones de código y refactors convenidos por el equipo, es que consigue (en mi opinión) crear la sensación de código del equipo. Se acabó el “esto lo hizo fulanito”, ahora el código es de todos, y todos somos responsables de fallos… y de genialidades 🙂

    Así lo he ido aprendiendo en los últimos años en Sevenclick y sobre todo ahora en Tenderoo… lo único que aún nos falta son las revisiones pactadas periódicamente… pero justo pactamos la semana pasada hacerlo los viernes a partir de ahora 🙂

    Os devuelvo el vídeo con otro, una variante del pair programming ( xDD ) http://www.youtube.com/watch?v=u8qgehH3kEQ

    • Julio García

      16 mayo, 2011 at 09:26

      Toda la razón jrubr. Se me olvido ponerlo, lo tenemos tan asumido ya que ni acordarme 😛 Me encanta oír que os funcionan las revisiones de código tan bien. Ánimo con las revisiones pactadas.

      Otra de las ventajas del código de equipo es que reduce el bus factor y permite que nadie sea imprescindible, para lo bueno y para lo malo…

      Me ha gustado mucho el vídeo, gracias 🙂

  2. Alejandro Lares

    16 mayo, 2011 at 14:22

    Hoy en dia las revisiones de codigo deberian ser un “MUST”

    Tiene muchisimas ventajas, de las cuales destacaria el conocimiento de todo lo que hace tu equipo y las areas afectadas. Lo que reduce la dependencia de inviduales, incrementando la flexibilidad de la empresa.
    Nosotros implantamos Crucible hara casi 2 años y la velocidad y calidad del equipo han incrementado notablemente.
    Esto combinado con algo de formacion en como escribir codigo limpio, hace que los “malos habitos” que (aunque algunos no quieran admitirlo) todos tenemos, se disminuyan de forma drastica.

    P.D: Saludos a mis antiguos compañeros!! (Aunque me volviese al sur sigo vuestros interesantes posts)

    • Señor Lares!!! Que alegría ver que nos sigues. Estoy contigo en tus comentarios sobre las reviews. Anda que como alguien revisara nuestro código JavaScript/HTML/CSS en los widgets le daba un ataque al corazón. Eso si que era Cowboy Coding!

      Gracias por comentar!

Deja un comentario

Tu dirección de correo electrónico no será publicada.

*