Si. Podemos. Si cumple todos los requirmientos funcionales y no funcionales que le hayamos puesto, entonces podemos decir que est\u00e1 bien. Por el contrario, si no cumple alguno de los requerimientos, est\u00e1 mal\/defectuosa. Y eso es todo lo que podemos decir objetivamente. Todo lo dem\u00e1s que no haya sido expresado como un requerimiento medible de si fue cumplido o no, pasa a ser subjetivo, o sea, una opini\u00f3n.
<\/p>\n\n\n\n
\u00bfEst\u00e1 poco legible? \u00bfEs inmantenible? Bueno, eso ya es como la belleza de una obra de arte: depende de qui\u00e9n lo mire. Para algunos, por ejemplo, escribir \u00ab{\u00bb en el rengl\u00f3n de abajo es un crimen. Para otros, es un standard. Para algunos, usar programaci\u00f3n funcional es la gloria, para otros, el infierno. Lenguaje fuertemente tipado vs d\u00e9bilmente tipado, tests unitarios versus pruebas manuales, React versus Angular, y as\u00ed, infinitos \u00abversus\u00bb que podemos nombrar. Tantos como programadores haya en el mundo. Y est\u00e1 bien. Esa diversidad es lo que hace que sea tan intelectualmente enriquecedora nuestra profesi\u00f3n.<\/p>\n\n\n\n
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\u00f1os despu\u00e9s. Y dentro del contexto tambi\u00e9n 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. <\/p>\n\n\n\n
Obviamente, podemos empezar a afinar la punter\u00eda y ver si determinado dise\u00f1o tarda m\u00e1s o menos en resolver el problema. Ahora… el tiempo era un requerimiento? Si no lo era, \u00bfcu\u00e1nta diferencia estamos dispuestos a tolerar? Si no establecimos un criterio de aceptaci\u00f3n, ya pasa a ser una opini\u00f3n. Algunas personas preferir\u00e1n sacrificar velocidad de ejecuci\u00f3n, en pos de mejor legibilidad, y otras no. Lo mismo con la cantidad de l\u00edneas de c\u00f3digo, estilo de nombramiento de variables, etc. <\/p>\n\n\n\n
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 \u00aben otras ocasiones anteriores, ante tal problema, se ha dado esta soluci\u00f3n y ha\/no ha funcionado\u00bb. Comunmente llamados \u00abbuenas pr\u00e1cticas\u00bb. 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\u00e1ctica en un equipo, buscando un determinado efecto, logremos el efecto contrario, porque quiz\u00e1s no sea el contexto adecuado. <\/p>\n\n\n\n
Trat\u00e1 de aprender todas las buenas pr\u00e1cticas que puedas. Trat\u00e1 de llegar a acuerdos de estilo de c\u00f3digo en tu equipo. Intent\u00e1 hacer medibles el cumplimiento o no de esos acuerdos. Pero fundamentalmente, ten\u00e9 en cuenta que no todos pueden compartir tu opini\u00f3n acerca de qu\u00e9 es o no una buena pr\u00e1ctica, y ten\u00e9 en cuenta que otras personas no necesariamente est\u00e1n viendo o vieron la misma pel\u00edcula que vos, y se flexible. Cont\u00e1 tu visi\u00f3n, escuch\u00e1 la del otro, que en el peor de los casos, si no lleg\u00e1s a un acuerdo, al menos, el va a conocer tu idea, y vos vas a conocer la suya. Y eso ya es un mont\u00f3n. <\/p>\n","protected":false},"excerpt":{"rendered":"