Saber Spring Boot no es lo mismo que saber desarrollar sistemas

 En los últimos años se ha vuelto común encontrar rutas de aprendizaje que llevan rápidamente a una persona desde los fundamentos básicos de programación hacia tecnologías como Spring Boot, React, Docker o servicios en la nube.

No considero que esto sea necesariamente negativo. El problema aparece cuando confundimos el conocimiento de estas herramientas con una formación completa en desarrollo de sistemas.

Una persona que recién termina la enseñanza secundaria puede perfectamente aprender Java, construir una API REST con Spring Boot, conectarla a una base de datos y desarrollar una interfaz web. Incluso puede llegar a trabajar profesionalmente con estas tecnologías.

Pero saber utilizar un framework no significa necesariamente comprender todos los conceptos que existen detrás de él.

La formación no consiste solamente en aprender tecnologías

Una tecnicatura o una ingeniería relacionada con informática normalmente no busca enseñar únicamente las herramientas que demanda el mercado en determinado momento.

Su propósito también es construir bases.

Programación, algoritmos, estructuras de datos, programación orientada a objetos, bases de datos, sistemas operativos, redes, análisis de sistemas, arquitectura, ingeniería de software y gestión de proyectos forman parte de un recorrido que ayuda a desarrollar una manera de analizar los problemas.

No significa que todo profesional recuerde perfectamente cada materia que estudió. Tampoco significa que una persona sin título no pueda adquirir esos conocimientos por su cuenta.

La diferencia está en haber pasado por un proceso formativo que obliga a mirar la informática desde distintas perspectivas.

El pensamiento crítico también forma parte del desarrollo

Uno de los resultados más importantes de esa formación debería ser el pensamiento crítico.

Cuando conocemos únicamente una herramienta, existe una tendencia natural a intentar resolver todos los problemas con ella.

Si conozco Spring Boot, la solución será Spring Boot.

Si conozco React, la interfaz será React.

Si aprendí microservicios, comenzaré a dividir el sistema en servicios.

Pero un desarrollador debería ser capaz de preguntarse antes:

¿Necesito realmente esta tecnología?

¿Qué problema estoy intentando resolver?

¿Qué ventajas me proporciona?

¿Qué complejidad incorpora?

¿Existe una solución más sencilla?

¿Qué ocurrirá cuando el sistema crezca?

¿Qué costo tendrá mantener esta decisión durante los próximos años?

El objetivo de la formación, entonces, no debería ser indicarnos permanentemente qué tecnología utilizar, sino entregarnos herramientas intelectuales para poder decidirlo.

También hay que entender el negocio

Existe además otro aspecto particularmente importante cuando hablamos de software empresarial.

Asignaturas relacionadas con administración de empresas, contabilidad, economía, costos, finanzas o gestión pueden parecer alejadas de la programación, pero ayudan a comprender el mundo donde finalmente funcionará el software.

Cuando desarrollamos un sistema de ventas, un ERP, un POS o una aplicación de facturación, no estamos simplemente almacenando objetos en una base de datos.

Estamos representando operaciones reales de una empresa.

Una venta puede afectar inventario, caja, impuestos, cuentas por cobrar y posteriormente los informes de gestión.

Una nota de crédito no es simplemente otro registro que insertamos en una tabla. Existe porque está corrigiendo o anulando una operación anterior y puede tener consecuencias tributarias, financieras y de inventario.

Por eso un desarrollador de software empresarial necesita, como mínimo, comprender el lenguaje de las personas para quienes construye el sistema.

No necesita convertirse en contador ni administrador de empresas. Necesita ser capaz de entender el problema que esas personas están intentando resolver.

El framework debería llegar después del concepto

Aquí es donde considero que existe un problema cuando la enseñanza comienza demasiado rápidamente con frameworks.

Podemos enseñar a construir una aplicación utilizando:

@RestController → @Service → @Repository → JPA

y obtener resultados rápidamente.

Pero también es importante que el estudiante comprenda qué existe debajo de esas abstracciones.

Por ejemplo:

HTTP → Servlet → Service → DAO → JDBC → SQL → Base de datos

No porque necesariamente debamos desarrollar todos nuestros sistemas modernos utilizando directamente Servlets y JDBC, sino porque conocer esas piezas permite comprender mejor qué trabajo está realizando posteriormente un framework.

Entonces Spring Boot deja de ser una colección de anotaciones que hay que memorizar.

Se transforma en una herramienta cuya utilidad podemos comprender y evaluar.

Acumular tecnologías no reemplaza una formación

Spring Boot, React, Docker, Kubernetes, AWS y cualquier otra tecnología pueden ser excelentes conocimientos profesionales.

Pero acumular tecnologías en un currículum no necesariamente significa haber desarrollado criterio para diseñar sistemas.

Las tecnologías además cambian.

Los fundamentos permanecen durante mucho más tiempo.

Por eso considero que existe una diferencia importante entre formarse para utilizar determinadas tecnologías y formarse para desarrollar sistemas.

La primera formación puede permitir incorporarse rápidamente a determinados puestos de trabajo.

La segunda intenta construir algo que demora bastante más: criterio.

Y probablemente una buena formación debería buscar ambas cosas.

Necesitamos conocer las herramientas que utiliza actualmente la industria, pero también necesitamos ser capaces de cuestionarlas, entender qué problemas solucionan y reconocer cuándo no son necesarias.

Al final, desarrollar software empresarial no consiste solamente en saber escribir código.

Consiste en comprender un problema, modelarlo, evaluar alternativas y recién entonces elegir las tecnologías con las que vamos a resolverlo.