Desarrollo Java
Desarrollo backend con Java para nuevas funcionalidades, aplicaciones empresariales y evolución de sistemas existentes.
Pedir diagnóstico gratuitoEl reto
Una aplicación empresarial puede necesitar nuevas funcionalidades, integraciones o mejoras sin necesidad de sustituir todo el sistema. El objetivo es construir soluciones mantenibles y adaptadas al contexto existente.
Eso implica trabajar dentro de las restricciones que ya hay: la versión de Java en uso, el servidor de aplicaciones, las dependencias que no se pueden tocar todavía y las pruebas que existen o que hay que construir primero.
Tecnologías
En una aplicación empresarial rara vez se elige el punto de partida. Se elige qué hacer con él.
Un desarrollo sobre un sistema en producción viene con condiciones puestas: una versión de Java concreta, un servidor de aplicaciones que no se puede mover todavía, dependencias que nadie quiere tocar y una cobertura de pruebas que es la que es. Ignorar esas condiciones y construir como si el proyecto fuera nuevo produce código que funciona en local y no se puede desplegar.
Trabajar dentro de ellas no significa perpetuarlas. Significa que cada funcionalidad nueva se construye de forma que no añada más deuda, y que las mejoras estructurales se hacen donde hay trabajo de todas formas, no en una tarea aparte que siempre se pospone.
En la práctica eso es lo que hace que una aplicación mejore sin proyectos de modernización: las zonas que se tocan van quedando mejor que como estaban. Cuando el deterioro es demasiado grande para arreglarlo por el camino, entonces sí hace falta un trabajo de modernización con alcance propio.
Lo que tienen en común es que hay un sistema existente de por medio. Un desarrollo desde cero, sin restricciones, casi nunca es el caso real.
Versión de Java, framework, servidor, cómo se construye, cómo se despliega y qué duele hoy. Una llamada de 30 minutos ahorra semanas de suposiciones, y a veces lo que sale es que no hace falta lo que se venía a pedir.
Algo pequeño, completo y desplegable. Sirve para validar el encaje técnico y la forma de trabajar antes de comprometer nada grande.
Cada entrega pasa por vuestra revisión y sale por el camino de siempre. Sin ramas largas: lo que no se despliega, no se sabe si funciona.
No como fase final, sino en el mismo commit. En una aplicación sin cobertura, cada funcionalidad nueva es la oportunidad de cubrir el flujo al que pertenece.
Lo que hace falta dentro de un año no es un comentario que repita la línea siguiente, sino saber por qué se descartó la alternativa obvia.
Cuatro capas, cada una con sus síntomas propios. Es útil saber cuál es la que está fallando antes de empezar a cambiar cosas.
| Capa | Síntoma habitual | Qué se revisa |
|---|---|---|
| Plataforma | No se puede subir una librería | Versión de Java, servidor de aplicaciones y árbol de dependencias |
| Persistencia | La aplicación se degrada según crecen los datos | SQL generado, consultas N+1 y límites de las transacciones |
| Integración | Un cambio en un sistema vecino rompe el nuestro | Contratos explícitos, tolerancia a fallos y reintentos |
| Entrega | Desplegar exige ventana y plan de vuelta atrás | Cobertura de pruebas, pasos manuales y configuración fuera del repositorio |
Aparecen cuando los datos crecen, no cuando se escribe el código, y por eso pasan las pruebas y fallan en producción.
LazyInitializationException: could not initialize proxyCausa: Se accede a una relación perezosa fuera de la transacción que cargó la entidad. Suele salir al serializar la respuesta, con la sesión ya cerrada.
Qué se hace: No alargar la transacción hasta la capa de presentación, sino cargar de forma explícita lo que hace falta, o trabajar con una proyección que solo traiga los campos necesarios.
Una pantalla que lanza 400 consultas para pintar 40 filasCausa: Consultas N+1: por cada elemento de una lista se lanza una consulta adicional para resolver una relación.
Qué se hace: Traer la relación en la misma consulta cuando de verdad se usa, y activar la traza de SQL en desarrollo. Un JOIN FETCH puntual resuelve la mayoría de los casos sin tocar el mapeo.
OutOfMemoryError al ejecutar un proceso por lotesCausa: El proceso carga la tabla entera en memoria porque la consulta no pagina y el contexto de persistencia no se vacía nunca.
Qué se hace: Procesar por bloques y limpiar el contexto en cada uno. Un proceso que funciona con mil registros y revienta con un millón no es un problema de memoria disponible.
Bloqueos que solo aparecen con carga realCausa: Dos flujos actualizan las mismas filas en orden distinto, o una transacción sigue abierta mientras espera a un sistema externo.
Qué se hace: Sacar las llamadas externas fuera de la transacción y unificar el orden de actualización. Reproducirlo exige concurrencia: con un solo usuario no aparece nunca.
Preguntas frecuentes
Sobre todo con aplicaciones que ya están en producción. Un desarrollo sin restricciones previas es la excepción: lo normal es que haya un sistema, un historial y unas condiciones que respetar.
Sí, y es lo habitual. Mismas reglas de revisión y mismo camino a producción que el resto del equipo. Un trabajo que llega en un paquete cerrado al final es imposible de revisar de verdad.
Se construyen sobre el flujo en el que se vaya a trabajar, como parte del encargo y no como extra. Cambiar código sin una red que demuestre que el comportamiento se mantiene es adivinar.
No siempre. Se puede desarrollar sobre la versión actual, y de hecho suele ser lo sensato al principio. Si la versión antigua es lo que bloquea el trabajo, se dice y se aborda como un trabajo aparte con su propio alcance.
No. El alcance llega hasta que la aplicación se construye, se prueba y se empaqueta de forma reproducible. Si vuestro proyecto necesita más que eso, os lo digo en la primera llamada.
JavaEvolve
Cuéntame qué hay montado y qué falta. Si el encargo no encaja con lo que hago, te lo digo en la primera llamada.
Pedir diagnóstico gratuitoLlamada de 30 minutos, sin coste. Respondo en menos de 48 horas.
En la llamada: versión de Java, framework, servidor y qué duele hoy. Si no puedo ayudarte, te lo digo. Qué incluye el diagnóstico