Te preparas para la entrevista, te ves los 5 cursos de turno lamentándote de lo que te enseñaron o no enseñaron, pasas las pruebas técnicas; estás listo para tus primer día de trabajo.
Hay tres cosas que (por lo general) pueden pasar cuando te presentan el código del proyecto:
- Todo te parece nuevo, esto claramente es ser junior
- Te sientes familiarizado y encuentras puntos de mejora, esto puede ser mid/senior, depende mucho de los casos claro.
- Querer salir huyendo
Cada vez que leo código de un proyecto empresarial mi mente empieza a evaluar varios factores:
Legibilidad
Que tan sencillo fue para mí leer el código que acabo de leer, eso me dice al instante cuánto le tomará al compañero leer lo mismo.
Un claro ejemplo es lo clásico que te enseñan al estudiar C o en javascript, que al solo tener una sentencia no es necesario colocar las llaves:
if (sed) agua();Acá a simple vista se comprende, pero al tener un archivo de 1000 líneas de código es mucho mejor leer esta condición con llaves:
if (sed) {
tomarAgua();
}Es mucho mejor escribir más; ya que, se suele usar minificadores, compiladores/transpiladores que optimizarán estas variables y funciones.
Debemos procurar crear código para humanos; pero esta decisión puede cambiar a partir del siguiente punto:
Las reglas del proyecto
Al crear un proyecto, hay diseños y patrones que se van estableciendo, incluso sin darte cuenta.
Volviendo al ejemplo del punto anterior, si el resto del proyecto, módulo o componente está de una forma, es válido evaluar si mejor seguimos escribiendo de ese mismo modo que ya fue establecido.
En este caso, si estoy viendo que el resto de ifs no tiene llaves, mejor seguir escribiéndolo así. Cabe destacar que si el factor de legibilidad es terrible, no dudo en cambiarlo y provocar una refactorización mayor.
Es mucho mejor seguir aplicando la misma solución a reinventar otra; para esto se utilizan linters, se crea documentación y se especifica un flujo.
Abstracción
Llega un punto en el proyecto que debes crear una función y no sabes que parámetros usar para que sea general en todos los casos posibles.
La idea es encontrar un equilibrio:
- Debes abstraer para acaparar la mayor parte de casos posibles
- No puedes abstraer todo, ya que llegarías al mismo código per se (el código es una abstracción del lenguaje de máquina)
Además hay dos reglas de oro que aplico al armar un componente/función:
- Si debo hacer lo mismo más de dos veces, es hora de abstraerlo
- Es mejor un componente duplicado a uno mal abstraído
De hecho esto no lo inventé yo; son varios patrones de diseño y buenas prácticas que he ido aprendiendo.
Complejidad
Si lo que estoy abstrayendo, la mejora que estoy aplicando o simplemente el código que estoy escribiendo tiende a ser muy complejo y da muchas vueltas; me pienso alguna alternativa o al menos lo documento si no tengo de otra.
Este punto a veces se puede vincular mucho con la legibilidad, pero puedes tener un código legible, pero con alta complejidad.
Por ejemplo cuando se taladran props, es legible pero agrega complejidad innecesaria; ya que para eso existe el uso de contexto.
Tiempo que me va a tomar
Siempre consciente que tengo un tiempo límite para aplicar la solución en un Sprint, el negocio no me va a esperar eternamente; pero a veces vale la pena dedicarle un poco más de tiempo.
Deuda técnica
Si la solución que voy a aplicar provocará una alta deuda técnica, me lo pienso dos veces; suele vincularse al factor de abstracción.
Si tengo tres componentes, puede que por tiempo y definición del negocio no lo abstraje en ese momento; pero sé que solo debo copiarlo aparte, colocarle unos cuantos parámetros y va a funcionar.
Reflexión Final
Esto son varios de los aspectos que diferencian el tener experiencia laboral contra el armar proyectos alternos o por tu cuenta; en una empresa no todo es como lo que te muestran en un curso o sigue las mejores prácticas.
Pero por otro punto de vista, siempre se debe tratar de aplicar las mejores prácticas y sobrellevarlas en conjunto al resto de tareas que son importantes para el negocio. Si no se atiende esta deuda técnica, se vuelve una bola de nieve sin control.
Por esto y por muchas otras razones existen los linters, patrones de diseño, flujos de trabajo, metodologías que tratan de estandarizar todo este mundo de la programación.
