Cómo mi primer Pull Request me bajó el ego

Cuando salí de la universidad me creía la raja. Había sido ayudante de casi todos los cursos de desarrollo de software y había trabajado en algunas cosas que sonaban muy cool. La verdad es que me sentía bien bueno en lo que hacía.

De hecho, durante los últimos años de universidad lo único que quería era salir y empezar a trabajar. Me sentía preparado mucho antes de mi egreso. Pero bueno, tenía que sacar el preciado cartón de ingeniero. Cuando salí de la sala después de rendir mi último examen fue uno de los mejores momentos de mi vida.

“Al fin. Al fin dejo de pagar por sufrir”.

Ahora me tocaba entrar al mundo laboral. “Ya he trabajado antes, debe ser bien parecido”. Para mí, entrar a trabajar era “coser y cantar”. Solamente tenía que aplicar lo que ya había aprendido y en poco tiempo iba a ser el crack del desarrollo de software.

Tenía que buscar donde empezar. Fui a varias entrevistas, pero al final me decidí por Platanus. Me gustó que era un lugar donde constantemente estaban pasando cosas. Ahí habían nacido Buda.com y Fintual. A mí me gustaban las criptomonedas y las finanzas. Me quedaba como anillo al dedo.

Cuando llegué a Platanus me pasaron altiro un proyecto que se veía bien entretenido. Iba a estar trabajando con Felipe y con Memo, que estaban en ese proyecto hace rato. Estaban usando Rails y Ionic. Rails ya lo conocía, me sentía bastante bueno en eso, así que no era gran problema. Nunca había trabajado en Ionic, pero ya había usado React Native y Android nativo. ¿Qué tan difícil podía ser?

En mi primera reunión con el cliente estábamos Jaime (el Scrum Master), Felipe y yo. La verdad es que no entendí mucho de lo que hablaban, pero sí caché que me asignaron mis primeras tareas. Eran tres o cuatro tarjetas de Trello que no se veían muy complicadas. De hecho, una tenía que ver con notificaciones push, tema en el que me había metido harto en otros proyectos. “Esta es la mía”, pensé. “Voy a hacer estas tarjetas bien rápido y voy a dejar a todos impresionados”.

Apenas salimos de la reunión empecé a trabajar con todo. Identifiqué las partes del código que tenía que tocar y me lancé a programar.

Después de dos días de trabajo, terminé la famosa primera tarjeta. Pensé que me iba a demorar menos, pero filo, me había quedado bien buena así que valía la pena. Sabía que tenía que hacer un Pull Request y pedirle a alguien que hiciera el code review. Se lo asigné a Felipe, porque era el que estaba metido en esa parte. Listo. Había terminado por el día.

Me fui a dormir pensando en lo bueno que me había quedado el código. “Me quedó la raja”. Era como de ésos códigos que uno le cuenta a los amigos (a los computines no más, a los otros me daría vergüenza). Mi primera pequeña victoria en mi nueva pega. Y lo iba a ver alguien más del equipo. Ideal. Me dormí con una sonrisa en la cara.

Al otro día decidí quedarme trabajando desde mi casa (Platanus es remote friendly). Me senté en mi escritorio con un buen café mañanero, listo para seguir en la senda ganadora. Abro Slack, y veo que tengo un mensaje de Felipe. Me dice algo como:

“buena andrew! oye avísame cuando te conectes pa’ que veamos tu pull request?”

Pensé: “Bah, qué raro, será que no ha tenido tiempo para verlo?”. Por un minuto pensé que quizás se me había olvidado crear el PR. Para verificarlo entré a Github. Me encontré con algo como esto:

“Mierda! Qué cresta pasó?!”.

La cuestión era un baño de sangre. Todo rojo y lleno de comentarios de “Monkeyci”, personaje del que nunca había escuchado.

“Quién es ese desgraciado?!”.

Estaba picadísimo. Y lo que más me dolió:

“felbalart requested changes”.

No entendía nada. Yo estaba tan orgulloso de mi código, y tan seguro de que todo estaba perfecto. Era imposible que tuviera algo malo.

Entré en la videollamada con Felipe. Me imagino lo que debe haber estado pensando: “Cómo cresta le digo a este compadre que todo lo que hizo está horrible”. Obviamente Felipe fue muy friendly y fuimos cambiando juntos las cosas del código que estaban malas. Nos demoramos un rato, pero tampoco tanto.

“Ya listo, terminamos”.

Cerramos la videollamada y subí los arreglos.

Se me ocurrió revisar los cambios que hicimos con Felipe respecto a lo que yo había hecho antes. Pensé: “Ya pero tampoco cambiamos tanto ahora, igual la base que hice debe haber quedado buena”. Todavía me tenía fe. Pero cuando revisé el PR me cayó la teja.

Todo el código que había hecho lo habíamos eliminado o cambiado de forma importante.

Y para más remate, los tests todavía no estaban pasando. Un desastre.

Después de llorar un rato en la almohada, decidí hacer un post-mortem y analizar cada una de las cosas que estaban mal con mi querido primer Pull Request.

1. El mono

El mono desgraciado. Este compadre es como el amigo que en medio del carrete te dice que no te tomes otra piscola: en ese momento lo odias, pero al otro día se lo agradeces.

Monkeyci es un bot de Github que revisa el código de todos los PRs. Está en constante búsqueda de su principal fuente de alimentación: los errores de estilo. Mientras más errores de estilo hay en un PR, más contento y gordo se pone el primate. Por cada uno de estos errores, este personaje agrega un comentario indicando exactamente cuál regla rompiste en esa linea de código. El famoso linter.

Antes de que pasara la catástrofe, yo encontraba que mi código había quedado impecable. Pero viendo hacia el pasado, me doy cuenta de que estaba bien feo todo. Al menos “feo” de acuerdo a los estándares y reglas que tenemos definidas en Platanus.

La solución para evitar que este desgraciado me comentara tanto fue instalar el linter en mi computador. Así cualquier error de estilo lo veo en vivo y en directo, y el mono me molesta menos.

Ahora mi relación con el mono es de amor y odio (harto más tirado pa’l odio). Pero si el mono no me avisara nada, o no le hiciera caso, terminaría con el hígado destrozado y haciendo un código horrible.

2. Tests

Lo otro que estaba fallando eran los tests. Resulta que para todos los repositorios de Platanus está configurado CircleCI. Este servicio corre los tests unitarios de la aplicación por cada push que se haga a Github. Así, uno se asegura de que no pase a staging código que rompa algo. Clave.

En mi primer PR hice algunos tests que “pasaban”, pero se me fue correr los que ya existían. Como no entendía mucho por qué estaban fallando, lo vimos con Felipe en la videollamada. Todavía me acuerdo de lo que dijo: “Al final los tests te dejan dormir tranquilo”. Cada día le encuentro más razón.

Platanus está bastante orientado al TDD (Test Driven Development). Yo creo que nunca en la universidad entendí la real importancia de hacer hartos y buenos tests. Nadie quiere que lo llame un cliente a las 11 de la noche diciéndole que todo está fallando. Prefiero perder 20 minutos haciendo tests que 2 horas de sueño varias noches a la semana.

3. Commits

Ah, los commits. Los commits de mi primer PR eran cualquier cosa. Me recuerdan a los commits del repositorio de chaucha.

Ya bueno, quizás no eran tan malos como ésos. Pero no eran buenos. En Platanus tenemos un estándar para los nombres de los commits. Este estándar está basado en conventional commits, y está en constante evolución y mejora. La idea es ojalá tener siempre un estándar con el que nos sintamos cómodos.

El objetivo es que los repositorios sean mantenibles y autoexplicativos. Una situación típica es que aparece un bug en un proyecto medio antiguo, y tenemos que encontrar donde se introdujo el error. Probablemente si hiciéramos malos commits nos demoraríamos infinito en encontrar la fuente de los problemas.

4. Code review

En mi primer PR me pidieron cambios.

“felbalart requested changes”

Esto significa que por alguna razón hay algo importante que mejorar. Cuando la revisión indica eso, por lo general el problema va más allá de los tests o del estilo. Suele tener que ver con hacer código más mantenible o que cumpla con buenos estándares de diseño de software.

Mi PR tenía algunos problemas de ese tipo. Tenía código duplicado en algunos lados, métodos en clases que no debían tener esa responsabilidad, etc.

Me dio un poco de vergüenza hacer un código malo, y me dio miedo pensar que iba a tener que enfrentar este proceso de juicio de nuevo en mi próximo PR. “Se van a reír de mi código y van a pensar que no cacho nada”. Pensamientos apocalípticos clásicos de cuando la inseguridad empieza a agarrar fuerza. Obviamente eso no pasó (o eso espero, quizás se están riendo de mí todavía).

Poner a evaluación de otro algo que hiciste con mucho esfuerzo siempre da un poco de susto. Uno siente que el otro está midiendo qué tan bueno eres. Recibir crítica no es fácil, en especial si la pides explícitamente. Es muy común querer quedarse piola, sabiendo que estás equivocado, pero sin querer que te lo digan. Es como cuando uno no quiere ir al doctor porque te va a decir que estás enfermo. A casi nadie le gusta que le digan que hizo una mala pega.

Pero pese a lo anterior, el proceso de code review es uno de las cosas que más me gustan de Platanus. Encuentro increíble que todos y cada uno de los desarrolladores de la empresa puedan recibir y dar feedback. El practicante, el veterano y el crack. Todos tienen que pasar por el humilde proceso de revisión. Y al final eso te hace mejorar. Y mucho. Uno nunca va a saber todo, y uno nunca va a hacer el código perfecto. El proceso de revisión de código se encarga de recordarte eso en cada PR. Además, si no existiera, no me daría tanta vergüenza hacer métodos gigantescos con variables llamadas ‘a’, ‘i’ o ‘n’. Inevitablemente se produce una presión por hacer las cosas mejor.

Lo que saco en limpio

De mi primer Pull Request aprendí mucho. Aprendí cosas en el PR que hice ayer, y estoy seguro que voy a aprender algo en el PR que voy a hacer mañana. Eso es algo que no tenía en mis pegas anteriores, y que tampoco tenía en los cursos de la universidad.

Esto no significa que en la U no haya aprendido nada. Efectivamente salí de ahí sabiendo muchas cosas. Pero ahora me doy cuenta de que esas cosas me van a servir de muy poco. Es trabajando en algo real, en la práctica, y con gente más seca que yo, que he aprendido cosas que me van a servir de verdad.

Lejos lo que más me ha ayudado son las revisiones de los PRs. Yo pensé que este proceso era algo común en las empresas de desarrollo. Me llamó la atención cuando compañeros de generación me contaban cosas como: “A nosotros nos pilló la máquina, así que empezamos a tirar todo a master de una”. O también: “Pucha, me gustaría que mis colegas se preocuparan de hacer las cosas mejor, no me esperaba esto en esta empresa”.

Parece que no es algo que se dé en todos lados. Yo creo que ahora me costaría mucho trabajar así. Una vez que se ha probado la buena vida, es como difícil volver atrás. De hecho, si pudiera volver en el tiempo, no trabajaría en proyectos solitarios donde no hay nadie con quién conversar y nadie de quién aprender. Entraría a una empresa donde haya gente que sepa más que yo. Una empresa donde se trabaje bien y se hagan cosas entretenidas. Hubiese ganado mucho más.

Y bueno, ya no me creo la raja. De hecho, probablemente soy uno de los que menos sabe en Platanus. Pero me gusta estar consciente de eso. Significa que puedo aprender mucho más que si estuviera en otro lado.