Code review

La revisión de código es un ejercicio social donde la tribu acepta la ofrenda y sacrificio del desarrollador en turno, para construir un proyecto que los dioses de los bugs bendigan.
-Alex, 2019

No tengo mucho que escribir sobre el acto de revisar código.

Para empezar, existe muchísima información al respecto y todos tienen una opinión homogénea de como hacer una buena revisión de código ( hay que ser asertivos en el proceso de revisar código, revisar más de 400 lineas de código suele ser contraproducente, si van a revisar tu código envíalo lo mejor y más limpio posible, ambas partes deben ser agradecidas, positivas y directas ).

Creo que, una correcta revisión de código, que fomente la comunicación y una buena cultura de trabajo en tu equipo, sin sacrificar tu productividad, se puede resumir en estos 2 post:

IBM: 11 proven practices for more effective, efficient peer code review de Jason Cohen

Proven Code Review Best Practices from Microsoft – Doctor McKayla

El pasado verano, al tener la gran oportunidad de trabajar en Facebook como interno, tuve una somera probadita de lo que implica que alguien en mi equipo (mi jefe, específicamente) revise mi código. También observé los problemas que pueden generarse si no se realiza adecuadamente ( y en tiempos correctos ) la revisión. Mi buen amigo Iván me contaba de vez en cuando, como su trabajo se acumulaba en el stack, porque nadie quería revisar su primer commit. Su experiencia es muy provechosa, interesante y en lo personal me moría de risa al escuchar sus lamentos, aquí dejaré su post.

De lo que puedo escribir y creo que será provechoso, es las prácticas que implementé de forma más o menos intuituva para no generarle un dolor de cabeza a mi manager mientras revisaba mi código.

Durante mi estancia en mi internship despertaba demasiado temprano todos los días, por lo que era el primero en llegar a la oficina. Durante esa hora libre me tomaba el tiempo para asegurarme de aislar los objetivos a realizar en pequeños objetivos.

Estos pequeños objetivos se volvían a pequeños commits, los cuales eran de tamaño decente para mi manager. ( Ya no se quejaba por el largo de los commits, se quejaba que producíamos demasiado en poco tiempo).

Aprender a ser objetivo y no tomarse personal las revisiones creo que es lo más complicado, separar trabajo de las emociones, separar el código del desarrollador.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Crea tu página web en WordPress.com
Empieza ahora
A %d blogueros les gusta esto: