De preguntas, sin respuestas

 

Un poco confundida 

 

 

Me molesta que algo que me gusta tanto como "el Arte de Programar" (si, el arte), se torne tan confuso.. Incluso de tantas preguntas que hago (a mi y a los demás) me siento sumamente ignorante y me pregunto si mientras más aprendo menos sé o si mis dudas son parte esencial de mi formación.

Debido a los grandes silencios que suelo escuchar, a que los libros dicen una cosa, mis colegas otra y los profesores otra he decidido pasar varias horas de este día por la Web en busca de alguna respuesta coherente, concisa y adecuada de la diferencia EXACTA entre Paradigma Estructurado, Procedural y Orientado a Objetos… Tengo idea… sé en qué consiste cada uno… Pero no puedo lograr dimensionar el punto, la línea en la cual se diferencian. No comprendo si esa línea es amplia o si la brecha que los separa es muy fina. Logro captar diferencias… pero al instante vuelvo a caer en preguntas, en respuestas incompletas y en formas de llevar a la práctica conceptos que varían inmensamente en la teoría.

La teoría me cierra… pero la práctica carece de toda coherencia. Y no logro resignarme, aceptar que a mi carrera le falta una base sólida de cómo hacer las cosas… y que es inevitable no entrar en pensamientos subjetivos y empíricos que poco tienen que ver con las metodologías. Por suerte me topé con un .pdf de una persona que se plantea preguntas que yo me he planteado, entre otras, y que me hacen ver que, al menos, no soy la única que por momentos se encuentra en una nube.

 

 

 

 

 

 

  

 

 

---

 

En busca de respuestas para la ingeniería de software por Nelson Medinilla Martínez

La construcción de software ha avanzado mucho, pero todavía hay innumerables preguntas importantes sin responder.

Los objetos software y el carnaval de serpentinas que los rodea parecen ser una moda. ¿Lo son? Últimamente, se oye una jerga de términos extraños (Java, C++, patrones, J2EE, …) en los bares, trenes, metro, y hasta en las cenas románticas, donde él usa esos términos, como el pavo real su cola, para demostrar a una ella (siempre aburrida). La misma treta puede dar resultados con los jefes, los entrevistadores de recursos humanos y los clientes que oyen lo que quieren oír, pero profesionalmente hablando:

¿Cuándo, cómo, por qué usar objetos en vez de estructurado? Más aún, ¿qué es estructurado y qué es objetos? ¿Cuánto de verdad hay en las ventajas que dicen los defensores de los objetos? ¿Conviene que el software sea un modelo de la realidad? ¿Por qué se cree que la modularidad del software facilita las modificaciones cuándo realmente no lo hace? ¿Qué hacer para facilitar las modificaciones del software?

¿Por qué fue distorsionada la programación estructurada original, al punto de creer hoy que es algo que no es? ¿Por qué ha sido maldecido y desvirtuado el principio de ocultación de información? ¿Por qué se han dejado de lado las estructuras abstractas de datos?

En el campo del proceso de construcción de software: ¿Cuándo usar una metodología u otra? Todas pugnan por ser adoptadas; sus autores dicen que expresan la mejor práctica, desde las clásicas hasta las recientes y hay cientos de metodologías para escoger. Todas se autoproclaman universales, sirven para construir cualquier software. Ninguna ingeniería tiene metodologías universales para construir cualquier producto. ¿En qué se diferencian unas de otras? Hay incluso metodologías con manifiestos, como aquél de “un fantasma recorre el mundo” ¿Se ha quedado la técnica sin argumentos técnicos y recurre a las emociones para ganar prosélitos?

¿Cómo interpretar una metodología de desarrollo de software? Por ejemplo, ¿el Proceso Unificado es una sucesión de ciclos en Cascada o es otra cosa, radicalmente distinta? ¿Se podría utilizar eXtreme Programming para construir software estructurado o mejor, qué metodología se debe usar con qué modelo de software? ¿Qué relaciones existen entre modelos de software (objetos, estructurado,…) y metodologías, considerando que hay metodologías estructuradas para diseñar software de objetos?

En temas más generales ¿por qué hubo que esperar hasta mediados de los noventa para incorporar los patrones al software, cuando los patrones son elementos cotidianos de cualquier profesión? ¿Por qué hay tan poca experimentación, en sentido estricto, en la ingeniería de software, cuando es usual en el resto de las ingenierías? ¿Por qué se ha abandonado prácticamente la línea de investigación sobre complejidad del software? ¿Por qué ha sido insuficiente el diluvio de metodologías? ¿Por qué tantas cosas sin responder?

Cada gurú tiene su propia respuesta, más aún cada constructor de software tiene la suya propia, que es la mejor, por supuesto. Prevalece el criterio de autoridad: “lo dijo fulano”. Pero faltan las respuestas universales que tiene cualquier ingeniería y su ausencia ha producido desconcierto, confusión, empirismo, frustración. Hay demasiadas alternativas y ninguna ofrece argumentos sólidos; se diseña objetos como si fuese estructurado, y se aplica el Proceso Unificado como si fuese un desarrollo en Cascada; casi nunca hay suficiente tiempo para los requisitos y casi nada de lo aprendido en los libros se utiliza en la práctica; para qué tanto estudio, si cualquiera construye software.