• A pesar de la experiencia de estos desarrolladores en lenguajes de programación procedimentales, como COBOL, C o FORTRAN, muchos de ellos pasaron por alto la oleada de tecnología de objetos que tuvo lugar en los primeros años noventa. Por lo tanto, muchos de ellos están comenzando desde el principio – es decir, intentando conseguir competencia básica con los conceptos de objetos para aprovechar el poder de un lenguaje de programación orientada a objetos como, por ejemplo, Java.

  El método para diseñar software anterior a la orientación a objetos se llamaba “descomposición funcional”. Con la descomposición funcional, se comenzaba con una descripción de la función general que una aplicación debía ejecutar – por ejemplo, “proceso de la planilla” – y, entonces, se procedía a descomponer este requerimiento funcional en subfunciones – por ejemplo, “entrada de tarjetas de asistencia”, “cálculo de cheques de pago”, “impresión de cheques de pago”. Esta descomposición (descendente) en unidades cada vez más pequeñas de funcionalidad continuaba hasta que se llegaba al punto en el que todas las unidades eran triviales de programar; entonces, se programaban primero las unidades funcionales más pequeñas, probándolas e integrándolas progresivamente en forma ascendente para construir una aplicación informática.

  Con la descomposición funcional, los datos se consideraban en forma tardía. Por el contrario, en el paradigma orientado a objetos, comenzamos concentrándonos en los datos que se necesitarán para servir como “columna vertebral” de nuestra aplicación: datos en forma de clases y objetos. Las funciones se consideran como un segundo paso en el proceso de modelado de objetos: sólo después de haber determinado la estructura de los datos de nuestras clases y objetos nos concentramos en los comportamientos que necesitamos ejecutar para colaborar en llevar a cabo el “objetivo” de la aplicación en su totalidad.

  Como puede atestiguar cualquiera que haya hecho la transición de la descomposición funcional a la programación orientada a objetos, cambiar de un enfoque centrado en las funciones a uno centrado en los datos cuando se diseña una aplicación parece, al principio, una inversión de conceptos y un paso atrás. Hacerlo representa un cambio importante de paradigma: o sea, un cambio fundamental en la forma en la que percibimos un problema de ingeniería del software, y de ahí que no sea algo que pueda dominarse rápidamente. De hecho, no es raro que los programadores necesiten un año o más de práctica antes de que “lo capten” y eso sólo si tienen disponible un experimentado ingeniero de software orientado a objetos que los guíe.

• Además de comprender los fundamentos del paradigma de objetos, se debe aprender también la sintaxis específica de Java para traducir los conceptos de orientación a objetos. Esto no es en sí mismo demasiado difícil, pero con ello viene la tarea desalentadora de familiarizarse con los cientos de clases preexistentes construidas en el lenguaje Java en forma de varias APIs o bibliotecas de clases (llamadas “paquetes” en Java) con el fin de (re)utilizarlas inteligentemente en nuestras aplicaciones.

• A continuación, surge el reto de comprender y dominar el paradigma de aplicaciones para el Web, el cual es, de nuevo, significativamente diferente del desarrollo tradicional de aplicaciones.

  • Primero, debemos aprender cómo trabajar en lo que es esencialmente un entorno “sin estado” debido a la dependencia de las aplicaciones en la Web del protocolo HTTP de “petición-respuesta”. En una aplicación tradicional (orientada o no a objetos), el programador tiene la posibilidad de guardar datos en la memoria mientras sirvan a un propósito útil de la aplicación (esto se llama, “datos que están en ámbito”). Por el contrario, en una aplicación Web, se deben aprender nuevas formas de conseguir que los datos persistan durante sus idas y venidas entre el navegador y el servidor.

  • En una aplicación convencional, típicamente se compila la aplicación en un único ejecutable o, en el caso de Java, se cargan varias clases y objetos en una única instancia de la Máquina Virtual de Java para ejecutar su lógica. Por contraste, los fragmentos de una aplicación Web están desunidos en forma de Java Server Pages (JSPs), formularios HTML, clases “bean” de apoyo, archivos de configuración XML y cosas así.

  • Se debe dominar una variedad de diferentes lenguajes (Java, JavaScript, HTML, XML, bibliotecas de etiquetas “a la medida”, etc.), cada uno con una sintaxis significativamente diferente, para trabajar estos variados componentes.

  • Incluso si todos los fragmentos se construyen sin fallos, la aplicación en su totalidad puede fallar si cualquiera de estos fragmentos se despliega incorrectamente en un servidor Web; estos problemas son difíciles de depurar.

  • Puede introducirse una miríada de problemas con respecto a la configuración de dichos entornos de despliegue – es decir, los servidores Web. Muchas veces, un desarrollador de aplicaciones Web “golpea su cabeza contra la pared” durante días, semanas o incluso meses, intentando depurar un problema de la aplicación que, al final, resulta ser un asunto de configuración del servidor Web.

  • Desgraciadamente, en muchas organizaciones, la responsabilidad de la administración del servidor Web recae sobre un grupo de individuos separados de los que desarrollan aplicaciones Web. Frecuentemente, se producen “batallas políticas” de acusaciones recíprocas entre las dos organizaciones sobre si una aplicación Web falla debido a un error de desarrollo o a un asunto de configuración del servidor Web.

• Para acabar, hay un conjunto de tecnologías de componentes J2EE particulares que deben dominarse –servlets, JSPs, JDBC, etc., cada una con sus propios obstáculos y retos conceptuales.

Sin importar la experiencia general de una persona como desarrollador de software, no es realista esperar que alguien que es:

pueda conseguir competencia en todo lo anterior en menos de un período de dos años y esto sólo si recibe capacitación formal y es guiado correctamente. ¡Aún así, no es raro que las organizaciones se embarquen en su primer proyecto J2EE esperando que sus desarrolladores “de legado”, comenzando de cero, puedan acercarse velozmente a todo lo anterior, entregando una aplicación J2EE robusta, no trivial y de objetivo crítico en seis meses o menos!

A menos que podamos transmitir a la gerencia cuán desalentadora es la tarea de reeducar una fuerza informática de trabajo en esas tecnologías, paradigmas y herramientas, los proyectos incumplirán repetidamente sus fechas límite, los desarrolladores se estresarán cada vez más, y las organizaciones en su totalidad se verán decepcionadas profundamente.

Compruebe la calidad de nuestro desarrollo offshore.
Aurum Solutions tiene experiencia en desarrollo offshore en J2EE y .NET de alta calidad y reducidos costos para empresas europeas y norteamericanas. Conozca nuestro desarrollo offshore haciendo clic aquí o en la página Web ../../offshore.html.

Cursos de Aurum Solutions relacionados con el tema de este artículo:
“Análisis y diseño orientado a objetos”
“Lenguaje de programación Java”
“Enterprise Javabeans”
“Programación en n-capas”
“Programación MVC usando Struts”
“Servlets y JSP”
“JavaScript”
“Seguridad en Java”
“Patrones de diseño”
“HTML”
“XML”
“Java Data Objects”
“Bibliotecas de etiquetas en JSP”
“Gestión de proyectos informáticos”