¿Podemos juzgar una pieza de software de manera objetiva y decir si está mal o bien?
Si. Podemos. Si cumple todos los requirmientos funcionales y no funcionales que le hayamos puesto, entonces podemos decir que está bien. Por el contrario, si no cumple alguno de los requerimientos, está mal/defectuosa. Y eso es todo lo que podemos decir objetivamente. Todo lo demás que no haya sido expresado como un requerimiento medible de si fue cumplido o no, pasa a ser subjetivo, o sea, una opinión.
¿Está poco legible? ¿Es inmantenible? Bueno, eso ya es como la belleza de una obra de arte: depende de quién lo mire. Para algunos, por ejemplo, escribir “{” en el renglón de abajo es un crimen. Para otros, es un standard. Para algunos, usar programación funcional es la gloria, para otros, el infierno. Lenguaje fuertemente tipado vs débilmente tipado, tests unitarios versus pruebas manuales, React versus Angular, y así, infinitos “versus” que podemos nombrar. Tantos como programadores haya en el mundo. Y está bien. Esa diversidad es lo que hace que sea tan intelectualmente enriquecedora nuestra profesión.
“Este es el camino, de otra forma está mal hecho”
Todas las herramientas tienen sus pro y contras, y su contexto. Una herramienta puede ser perfecta para un determinado momento de la empresa, y terrible para la misma empresa unos años después. Y dentro del contexto también incluyo al equipo. Una herramienta puede ser espectacular usada por un cierto grupo de personas, con determinadas vivencias y conocimientos, y puede ser terrible usada por otros. Y no por eso la herramienta es mas o menos. O inclusive, no significa que un grupo de personas sea mejor o peor que el otro. Simplemente son distintos, y ciertas combinaciones en algunos contextos resultar mejores que otras.
Obviamente, podemos empezar a afinar la puntería y ver si determinado diseño tarda más o menos en resolver el problema. Ahora… el tiempo era un requerimiento? Si no lo era, ¿cuánta diferencia estamos dispuestos a tolerar? Si no establecimos un criterio de aceptación, ya pasa a ser una opinión. Algunas personas preferirán sacrificar velocidad de ejecución, en pos de mejor legibilidad, y otras no. Lo mismo con la cantidad de líneas de código, estilo de nombramiento de variables, etc.
“Entonces hagamos lo que se nos cante”
Lo anterior no quiere decir que podamos hacer impunemente lo que nos venga en gana. La comunidad de programadores ha ido cosechando vivencias a lo largo de la historia, y se han ido formando conjuntos de experiencias, del tipo “en otras ocasiones anteriores, ante tal problema, se ha dado esta solución y ha/no ha funcionado”. Comunmente llamados “buenas prácticas”. Pero de esto tenemos que ser conscientes: son opiniones, compartidas por grupos de personas, hechas en base a valoraciones (objetivas o subjetivas) de experiencias pasadas. Y no todos pueden haber tenido las mismas experiencias. Puede que por ejemplo, si intentamos imponer una determinada práctica en un equipo, buscando un determinado efecto, logremos el efecto contrario, porque quizás no sea el contexto adecuado.
¿Bueno, y qué hago?
Tratá de aprender todas las buenas prácticas que puedas. Tratá de llegar a acuerdos de estilo de código en tu equipo. Intentá hacer medibles el cumplimiento o no de esos acuerdos. Pero fundamentalmente, tené en cuenta que no todos pueden compartir tu opinión acerca de qué es o no una buena práctica, y tené en cuenta que otras personas no necesariamente están viendo o vieron la misma película que vos, y se flexible. Contá tu visión, escuchá la del otro, que en el peor de los casos, si no llegás a un acuerdo, al menos, el va a conocer tu idea, y vos vas a conocer la suya. Y eso ya es un montón.