Hoy les quiero hablar sobre un tema álgido entre programadores, que genera auténticas batallas entre compañeros de trabajo y más entre ex-compañeros de trabajo… aquí juega mucho el famoso “ego del programador”, esas ideas que crees que te hacen ver súper experto pero, en realidad, muestran lo intolerante, falto de ideas y otras muchas cosas negativas que nadie quiere.
De acuerdo a la escuela de cada programador, aquí podemos tener una serie de opiniones que difieren muchísimo y algunos se enfrascan en querer imponer su realidad. Precisamente la realidad de cada quien es la que debería responder la pregunta objeto de este artículo, PERO considerando que éstas (realidades) dependen del proyecto en el que se esté colaborando.
Cada proyecto de desarrollo en el que colaboramos tiene sus objetivos particulares que definirán la ruta que debemos seguir… tecnologías, herramientas, requerimientos seguridad, perfiles de desarrolladores, requerimientos funcionales, entre otras cosas.
Un factor determinante en la forma de resolver los requerimientos tiene que ver con la operación que se va a automatizar. Como regla general en estos tiempos, toda la lógica de negocios se programa en el aplicativo y se hacen las consultas que sean necesarias a la base de datos.
Esto está muy bien cuando el volumen transaccional es bajo y/o la cantidad de datos que se va a procesar no es importante (en cuanto a cantidad)… y esto es lo que ocurre, normalmente, cuando se está desarrollando y cuando se están haciendo pruebas para liberar a producción. La historia cambia cuando se empiezan a manejar muchos datos o un alto volumen transaccional… aquí empieza la diversión.
Les voy a contar una anécdota interesante. En un proyecto en el que participé, se liberó un proceso que hacía que la operación se paralizara… ¡por más de una hora! Es decir, el proceso era tan lento cuando se procesaban más de 50,000 registros, que todas las personas que participaban en el proceso tenían que esperar. Obviamente, fallaron muchas cosas para llegar a ese punto pero, una de las más importantes, fue la falta optimización que ameritaba el proceso.
Para este proyecto en particular, todos los miembros del equipo tuvimos que aprender una serie de técnicas para optimizar el manejo de ese volumen de datos y fue necesario programar la lógica del negocio en la base de datos.
Algunas personas de la vieja escuela dirán que estoy descubriendo el “agua tibia”, sin embargo, hay un trasfondo importante… considero que no se nos está preparando adecuadamente a los programadores (y profesionales de TI en general) para afrontar los desafíos de la industria.
Mi consejo a los programadores que están aprendiendo (y los que no pero que aceptan críticas constructivas) es que no se casen con una tecnología, con una forma de trabajar; todas las ideas, técnicas y enfoques para la resolución de problemas son importantes y deben considerarse para resolver los retos que propone el proyecto en el que se está trabajando.
La respuesta a la pregunta es que depende de la naturaleza del proyecto… “al César lo que es del César”.
Comentarios recientes