En las dos partes anteriores de nuestra serie hablamos sobre los primeros pasos en la profesión de programador y sobre lo que realmente vale la pena aprender al inicio de la carrera.
Ahora llegamos al momento que casi todo Junior teme.
Primer Code Review. Primeros comentarios al código. Primeras correcciones.
Y el primer pensamiento: "¿De verdad escribí tan mal este código?"
Tranquilo.
Todos nosotros hemos pasado por eso alguna vez.
El Code Review no es un examen
Probablemente es el mayor malentendido entre los programadores que están empezando.
Muchos Juniors toman los comentarios sobre su código de forma muy personal. Aparece el estrés. La incertidumbre. A veces incluso la frustración.
Y, sin embargo, el objetivo del Code Review no es demostrarle a alguien que cometió un error. Al contrario. Es uno de los elementos más importantes del proceso de crear buen software.
Gracias al Code Review:
- reducimos el riesgo de errores,
- mejoramos la legibilidad del código,
- aprendemos unos de otros,
- mantenemos la coherencia de todo el proyecto,
- transferimos conocimiento entre los miembros del equipo.
Los mejores equipos no tratan al Code Review como un control. Lo ven como un intercambio diario de experiencias.
"Tienes 37 comentarios"
¿Suena intimidante? Al principio sí.
El primer Pull Request a menudo se parece exactamente a esto:
- Comentario.
- Corrección.
- Otro comentario más.
- Otra corrección.
Después de una hora tienes la sensación de que todo el código debería tirarse. Es normal.
Solo recuerda una cosa. El senior no corrige el código porque quiera demostrar su superioridad. Lo hace porque dentro de unos meses escribirás un código mucho mejor.
Y de eso se trata.
Un buen Senior no dice solo "mal"
Los mejores programadores con los que hemos trabajado siempre explicaban:
- por qué vale la pena hacerlo de otra manera,
- cuáles serán las consecuencias de la solución actual,
- qué alternativas existen,
- qué solución será más fácil de mantener dentro de un año o dos.
Eso marca una gran diferencia.
Porque se puede decir: "Esto está mal."
O se puede decir: "Esto funcionará, pero si en seis meses vamos a desarrollar este módulo, será mucho más fácil mantenerlo con esta estructura."
En el segundo caso aprendes algo mucho más valioso que la simple corrección. Aprendes una forma de pensar.
Clean Code no significa código bonito
Es otro concepto que a menudo se entiende mal.
Clean Code no significa código que se vea espectacular. No se trata del número de líneas en blanco. No es sobre la longitud de las funciones. Ni siquiera sobre patrones concretos.
Se trata de algo mucho más simple: el código debe ser legible.
Si dentro de medio año abres tu propio proyecto y no recuerdas lo que tenías en mente...
...probablemente el código no era lo suficientemente legible.
Hay un dicho: Escribimos código para personas. El compilador solo comprueba la sintaxis.
Y hay mucha verdad en eso.
No te enamores de tu propio código
Esta es una de las lecciones más importantes.
El código no es una obra de arte. No es un cuadro. No es una escultura.
Es una herramienta para resolver un problema concreto.
Si alguien propone una solución mejor...
...vale la pena considerarla.
No porque alguien tenga más autoridad. Porque quizás realmente sea mejor.
Los que más aprenden son los programadores que pueden decir: "Tienes razón. Hagámoslo diferente."
"En mi funciona"
Bien. Tarde o temprano teníamos que llegar a esta famosa frase. Cada software house tiene su versión de este chiste...
Imagina la situación.
Un tester informa un error.
El programador responde: "En mi funciona."
El tester comprueba de nuevo. - No funciona.
El Project Manager mira. - No funciona.
El cliente también comprueba. - No funciona.
Pero... en la máquina del autor del código sigue funcionando.
¿Suena familiar?
Normalmente el problema no está en el propio código.
Las causas pueden ser muchas:
- otra versión de los datos,
- otro entorno,
- cache,
- configuración,
- permisos,
- navegador,
- sistema operativo,
- un caso que nadie había previsto antes.
Por eso un programador profesional no termina el análisis con la frase: "En mi funciona."
Hace la siguiente pregunta.
¿Por qué en mi funciona y en otro lugar no?
Y ahí es cuando comienza la verdadera depuración.
"Es solo un pequeño cambio"
Otra frase que provoca una sonrisa en la mayoría de los software houses.
El cliente dice: "Es solo una pequeña corrección."
El programador ya sabe que al momento abrirá un archivo que nadie ha tocado en seis años.
Y esa "pequeña corrección" resultará ser un cambio en cinco módulos, tres integraciones y dos bases de datos.
Por eso los desarrolladores experimentados son muy cautelosos con la palabra "solo".
Las frases más conocidas de la industria
Cada profesión tiene sus dichos. Los programadores también.
Algunos de ellos probablemente los conoce casi todo el mundo:
- "En mi funciona."
- "Solo cinco minutos."
- "No es un bug. Es una feature."
- "Pero no cambié nada."
- "En producción se cayó."
- "Solo un deploy más."
- "Seguro que es caché."
- "Una corrección rápida antes del fin de semana."
- "Debería funcionar."
Y probablemente la más peligrosa: "Lo desplegamos a producción el viernes después de las 16:00."
Si trabajas en TI...
...probablemente acabas de sonreír.
El programador no trabaja solo
Este es un tema que a menudo se pasa por alto. En realidad, la mayoría de los proyectos son trabajo en equipo.
El programador colabora con:
- UX Designers,
- UI Designers,
- Project Managers,
- Testers,
- DevOps,
- Administradores,
- Analistas,
- Clientes.
Por eso, tan importantes como los conocimientos tecnológicos son:
- comunicación,
- capacidad de escuchar,
- transferencia de conocimiento,
- responsabilidad,
- respeto mutuo.
El mejor código no salvará un proyecto si el equipo no sabe trabajar en conjunto.
Glosario de términos
Code Review
Proceso de revisión de código por otros programadores antes de su despliegue. Su objetivo es mejorar la calidad del código, detectar errores y compartir conocimiento.
Pull Request (PR)
Propuesta de introducir cambios en el proyecto. Es en esta etapa donde con mayor frecuencia se realiza el Code Review.
Clean Code
Enfoque para escribir código cuyo objetivo principal es la legibilidad, la simplicidad y la facilidad de mantenimiento, no la cantidad de patrones aplicados.
Depuración (Debugging)
Proceso de encontrar y eliminar las causas de los errores en una aplicación.
Cache
Mecanismo que almacena datos temporalmente para acelerar la aplicación. A menudo es también fuente de problemas misteriosos durante las pruebas.
Resumen
Cuanto más tiempo trabajamos como programadores, más llegamos a una conclusión. Los mejores desarrolladores no son los que cometen menos errores.
Los mejores desarrolladores saben:
- encontrar la causa de un problema más rápido,
- extraer conclusiones,
- aprender de otros,
- aceptar crítica constructiva,
- desarrollar continuamente su oficio.
Por tanto, el Code Review no es un obstáculo. Es una de las lecciones más valiosas que puedes recibir al comienzo de tu carrera.
En la última parte de nuestra serie hablaremos sobre el camino de Junior a Senior. Explicaremos por qué un Senior Developer no es una persona con diez años de experiencia, sino alguien que sabe responsabilizarse por un proyecto, pensar en términos de negocio y ayudar a que los demás miembros del equipo se desarrollen.
