En la empresa para la que trabajo, hemos tenido un proyecto en el que los desarrolladores escribieron una aplicación por lotes que leería una gran base de datos y consumiría algunos servicios (no exactamente servicios web … algunos eran interfaces basadas en sockets para sistemas heredados). Eligieron Spring Batch (porque era un estándar de la casa) y JPA e Hibernate por estar familiarizados con la tecnología y comenzaron a desarrollar esta aplicación por lotes. Pero había muchas otras cosas pequeñas y complicadas, como la integración con sistemas y bases de datos heredados.
Sin embargo, cuando me acerqué al equipo para revisar su código, les aconsejé que no usaran relaciones uno a muchos para evitar consultas N + 1, almacenar en caché los sistemas externos, hacer que partes del trabajo sean paralelas, aumentar el tamaño del fragmento en lugar de enfocarse únicamente en consistencia, evite 2PC siempre que sea posible, escribiendo flujos alternativos para que el trabajo considere la tolerancia a fallas y otro tipo de cosas. Sin embargo, algunos miembros del equipo argumentaron que todas esas afirmaciones eran algún tipo de optimización prematura y, en parte, tenían razón. Muchos de mis consejos no fueron seguidos de inmediato.
Cuando estaba cerca de la fecha límite de lanzamiento, realizaron una prueba en una base de datos de producción con un volumen realmente alto (miles de millones de registros). La aplicación por lotes fue tan lenta que estimamos que llevaría un año y medio realizar todas las operaciones. Entonces, mi equipo fue convocado para ayudar a los desarrolladores a mejorar el rendimiento de la aplicación.
- Estoy trabajando en una empresa de TI como desarrollador de software y necesito cambiar a roles de administración. ¿Hay alguna salida sin hacer MBA?
- ¿Cuál es la mejor manera para que un desarrollador de software haga la transición de TI corporativa a nuevas empresas?
- ¿Cuál es la diferencia entre el desarrollo de software ágil y CMMI?
- ¿En qué debería centrarme, ser un desarrollador de software desempleado?
- ¿Cómo vería la industria del software a un candidato que haya trabajado como desarrollador de software en una universidad?
Bueno, no fue bonito. Lo que se suponía que era inicialmente un proyecto fácil, llevó a todos los equipos al límite. Hemos tenido menos de un mes para realizar una revisión completa de la solicitud, con muchas horas extras. Afortunadamente, había mucho espacio para mejoras, por lo que pudimos reducir el tiempo de ejecución completo a menos de una semana. Tuvimos que tomar algunas decisiones arriesgadas porque tuvimos que pasar un tiempo de la ventana para ejecutar el lote para hacer algunas optimizaciones y ajustes finales en la infraestructura.
La cuestión es que las personas generalmente siguen “mantras” sin comprender realmente su contexto, como si fuera algo sagrado. Si bien realizar una optimización prematura en un dominio del que no sabe nada es malo, porque ciertamente pasará mucho tiempo para mejorar algo que no importará una vez que obtenga una visión general, es imprudente ignorar la experiencia y el conocimiento previos sobre problemas que ya has resuelto.
Lo importante fue que, al final, todos hemos aprendido mucho. ¡Hemos hecho un buen estudio de caso sobre toda la experiencia para el resto de la compañía! Y, por supuesto, el equipo de desarrollo hizo un gran trabajo.