Un día un pibe programador dijo "Ché, qué es esta variable rorColo" y vino Mister Old Grandpa a decirle "Es true cuando hay un error en el proceso de colocación."
A la papirola.
Y nunca faltan esas tablas llamadas USRPIJATBL001 o lo que es peor, que todos los datos se repitan en todas las tablas, haya o no FK.
Grandes monstruos se han construído sobre el estiércol del día a día. "Necesito un string ya. A ver... oh si, string93". Claro que estoy hablando casos extremos, que he visto poco (por suerte!). Sin embargo, muchísimos sectores de sistemas en muchas empresas están caldeadas y pelean día a día con estos problemas. Con leer The Daily WTF ya nos damos una idea.
Por otro lado es común que las variables, clases, etc, se nombren como vienen, y no se respete ningún estándar. Y sólo estoy hablando de nomenclaturas. Podemos escribir estándares sobre cualquier situación "estándar" que se nos ocurra.
Este post es para divagar un poco sobre qué ocurre y de quién es la culpa cuando esos estándares existen, pero no se respetan. ¿Están mal escritos? ¿Los empleados son rebeldes?
Vamos a analizar los actores. ¿Pero por dónde empezar? ¿Desde el management o desde la fuerza de programadores rasos? Y bueno, empecemos de arriba a tirar palos.
El management y los arquitectos que desarrollan el estándard...
Un estándard de programación tiene que pasar a formar parte de la cultura de tu empresa, porque afecta directamente a la calidad del producto software que vas a crear. Estés o no en una empresa cuyo negocio central sea sistemas, deberías siempre apuntar a hacer software de calidad, y el software se construye de muchas cosas, pero una de ellas es el código. Y en el código podemos poner solamente código o podemos implementar un modelo realmente bien pensado de forma arquitectónica para aprovechar las ventajas de las buenas prácticas.
Entonces, si debe ser parte de la cultura de la empresa, y parte del proceso de creación de productos con calidad, ¿No es una tarea importante del management (en conjunto con los arquitectos) que se implemente? Yo opino que sí. Cuando entré en uno de mis trabajos me hicieron leer guias y guias de estándares, y siempre los respeté todos. Empecé a trabajar en un sector que los utilizaba y realmente creía ver código conciso y pensar que lo podría haber hecho cualquiera. Sin embargo, luego me moví a otro sector que era todo lo contrario. ¡Un desastre!
Poco a poco fuí impulsando cambios (desde abajo, como programador) para intentar mejorar la aplicación de los estándares, además de otras cosas. Pero nunca nadie de arriba se interesó por si estábamos haciendo las cosas bien o no. Cada uno de nuestros proyectos tenía un arquitecto asignado. Sólo lo conocí en un curso, y nada más. Ni siquiera se interesó cuando se arrancó un proyecto impulsado por el sector mismo, para construir un framework de SharePoint.
Sin interés de arriba el único que puede impulsar un cambio es uno, pero lo más probable es que los cambios significativos sólo fuesen a impactar en nuestro sector y nada más. Es un estándar tirado a la basura porque no se implementa ni se promueve.
Los project managers...
Un PM se la pasa pensando en fechas de entrega, implementaciones, y tareas pendientes. Casi nunca un PM te vá a decir "che y si rehacemos el módulo X?". Tienen un trabajo bastante cargado, y son apurados por el mismo management. Sin embargo, de vez en cuando deberían impulsar cambios a mejoras en la calidad y promover la implementación de estándares. Si tus programadores trabajan mejor, se entienden mejor, y hacen las cosas más rápido, ¿no van a mejorar los resultados?. Obviamente.
Pero es difícil parar la pelota, encontrar el tiempo, y pensar la jugada. Pero lo lamento, también los culpo.
Los analistas técnicos y programadores seniors...
Si se nos presenta un estándar de programación es nuestra responsabilidad aplicarlo, independientemente de cómo trabaje el resto y del código con el que estemos trabajando. Así que si no aplicamos un estándar... obviamente, es NUESTRA culpa también. Nadie está exento.
Además, como miembros más experimentados y/o más antiguos, hay que impulsar la implementación a los programadores más novatos. Se les debe inculcar la cultura de la calidad, y una de las cosas que eso requiere es el uso de estándares.
Es culpa de todos. Promuevan y apliquen los estándares. Y si no tienen uno, es buen momento para arrancar.
Yo estoy a punto de escribir uno para la empresa en donde estoy, donde voy a usar mi experiencia propia más estándares que ya conozco. Una vez terminado, sea aceptado o no, lo publicaré aquí.
No comments:
Post a Comment