Code Complete | Metáforas para una comprensión más rica del desarrollo de software

admin/ mayo 26, 2017/ code complete, desarrollo de software, fundamentos, Metáfora/ 0 comments

Contenido

  • La importancia de las metáforas
  • Cómo usar las metáforas del software
  • Metáforas comunes del software

La importancia de las metáforas

Acontecimientos importantes a menudo surgen de las analogías. Al comparar un tema que usted entiende mal a algo similar que usted entiende mejor, puede llegar a ideas que dan lugar a una mejor comprensión del tema menos familiar. Este uso de la metáfora se llama “modelado”.

La historia de la ciencia está llena de descubrimientos basados ​​en la explotación del poder de las metáforas. El químico Kekulé tuvo un sueño en el que vio una serpiente agarrar su cola en su boca. Cuando despertó, se dio cuenta de que una estructura molecular basada en una forma de anillo similar tendría en cuenta las propiedades del benceno. La experimentación posterior confirmó la hipótesis (Barbour 1966).

La teoría cinética de los gases se basó en un modelo de “bola de billar”. Se pensó que las moléculas de gas tenían masa y chocaban elásticamente, como las bolas de billar, y muchos teóricos útiles se desarrollaron a partir de este modelo.

La teoría ondulatoria de la luz se desarrolló en gran parte explorando similitudes entre la luz y el sonido. La luz y el sonido tienen amplitud (brillo, intensidad), frecuencia (color, tono) y otras propiedades en común. La comparación entre las teorías ondulatorias del sonido y la luz fue tan productiva que los científicos pasaron un gran esfuerzo buscando un medio que propagara la luz de la forma en que el aire propagaba el sonido. Incluso le dieron un nombre – “éter” – pero nunca encontraron el medio. La analogía que había sido tan fructífera en algunos aspectos resultó ser engañosa en este caso.

En general, el poder de los modelos es que son vívidos y pueden captarse como conjuntos conceptuales. Sugieren propiedades, relaciones y áreas adicionales de investigación. A veces un modelo sugiere áreas de investigación que son engañosas, en cuyo caso la metáfora ha sido exagerada. Cuando los científicos buscaron el éter, ampliaron su modelo.

Como es de esperar, algunas metáforas son mejores que otras. Una buena metáfora es simple, se relaciona bien con otras metáforas relevantes, y explica gran parte de la evidencia experimental y otros fenómenos observados.

Considere el ejemplo de una piedra pesada que hace pivotar hacia adelante y hacia atrás en una cuerda. Antes de Galileo, un aristotélico que miraba la piedra que balanceaba pensó que un objeto pesado se movió naturalmente de una posición más alta a un estado del resto en una más baja. El aristotélico pensaría que lo que la piedra estaba haciendo realmente estaba cayendo con dificultad. Cuando Galileo vio la piedra oscilante, vio un péndulo. Pensó que lo que realmente hacía la piedra era repetir el mismo movimiento una y otra vez, casi perfectamente.

Los poderes sugestivos de los dos modelos son muy diferentes. El aristotélico que vio caer la piedra oscilante observaba el peso de la piedra, la altura a la que se había elevado y el tiempo que tardó en descansar. Para el modelo de péndulo de Galileo, los factores prominentes eran diferentes. Galileo observó el peso de la piedra, el radio del columpio del péndulo, el desplazamiento angular y el tiempo por oscilación. Galileo descubrió leyes que los aristotélicos no pudieron descubrir porque su modelo les llevó a mirar fenómenos diferentes y hacer preguntas diferentes

Las metáforas contribuyen a una mayor comprensión de las cuestiones de desarrollo de software de la misma manera que contribuyen a una mayor comprensión de las cuestiones científicas. En su conferencia del Premio Turing de 1973, Charles Bachman describió el cambio de la visión imperante centrada en la tierra del universo a una visión centrada en el sol. El modelo de tierra de Ptolomeo había durado sin problemas durante 1400 años. Luego en 1543, Copérnico introdujo una teoría heliocéntrica, la idea de que el sol y no la tierra era el centro del universo. Este cambio en los modelos mentales condujo en última instancia al descubrimiento de nuevos planetas, la reclasificación de la luna como un satélite más que como un planeta, y una comprensión diferente del lugar de la humanidad en el universo.

Bachman comparó el cambio ptolemaico a copernicano en la astronomía con el cambio en la programación de computadoras a principios de los años setenta. Cuando Bachman hizo la comparación en 1973, el procesamiento de datos estaba cambiando de una visión centrada en la computadora de los sistemas de información a una vista centrada en la base de datos. Bachman señaló que los antiguos del procesamiento de datos querían ver todos los datos como un flujo secuencial de tarjetas que fluyen a través de un ordenador (la vista centrada en el ordenador). El cambio consistía en centrarse en un grupo de datos sobre los que actuaba el ordenador (una vista orientada a la base de datos)

El valor de las metáforas no debe ser subestimado. Las metáforas tienen la virtud de un comportamiento esperado que es entendido por todos. La comunicación innecesaria y los malentendidos se reducen. El aprendizaje y la educación son más rápidos. En efecto, las metáforas son una forma de interiorizar y abstraer los conceptos, permitiendo que el pensamiento esté en un plano superior y se eviten errores de bajo nivel.
– Fernández J. Corbató

Hoy es difícil imaginar a alguien pensando que el sol se mueve alrededor de la tierra. Del mismo modo, es difícil imaginar a un programador pensando que todos los datos podrían ser vistos como un flujo secuencial de tarjetas. En ambos casos, una vez que la vieja teoría ha sido descartada, parece increíble que alguien alguna vez lo creyó en absoluto. Más fantásticamente, la gente que creía que la vieja teoría pensaba que la nueva teoría era tan ridícula entonces como usted piensa que la vieja teoría es ahora.

La visión centrada en la tierra del universo cojeaba a los astrónomos que se aferraban a él después de que una teoría mejor estuviera disponible. Del mismo modo, la visión centrada en la computadora del universo computacional enturbió a los científicos informáticos que se aferraron a ella después de que la teoría centrada en la base de datos estuviera disponible.

Es tentador trivializar el poder de las metáforas. A cada uno de los ejemplos anteriores, la respuesta natural es decir: “Bueno, por supuesto, la metáfora correcta es más útil. ¡La otra metáfora estaba equivocada!” Aunque esa es una reacción natural, es simplista. La historia de la ciencia no es una serie de cambios de la metáfora “incorrecta” a la “correcta”. Es una serie de cambios de metáforas “peores” a “mejores”, de menos inclusivo a más inclusivo, de sugerente en un área a sugestivo en otro.

De hecho, muchos modelos que han sido reemplazados por mejores modelos todavía son útiles. Los ingenieros todavía resuelven la mayoría de los problemas de ingeniería usando la dinámica newtoniana aunque, teóricamente, la dinámica newtoniana ha sido suplantada por la teoría de Einstein.

El desarrollo de software es un campo más joven que la mayoría de las otras ciencias. Todavía no está lo suficientemente maduro como para tener un conjunto de metáforas estándar. Consecuentemente, tiene una profusión de metáforas complementarias y conflictivas. Algunos son mejores que otros. Algunos son peores. Lo bien que entiende las metáforas determina cuán bien entiende el desarrollo de software.

Cómo utilizar las metáforas del software

Punto Clave

Una metáfora de software es más como un reflector que como una hoja de ruta. No le dice dónde encontrar la respuesta; Te dice cómo buscarlo. Una metáfora sirve más como una heurística que como un algoritmo.

Un algoritmo es un conjunto de instrucciones bien definidas para llevar a cabo una tarea en particular. Un algoritmo es predecible, determinista y no sujeto al azar. Un algoritmo le dice cómo ir desde el punto A al punto B sin desvíos, sin desplazamientos laterales a los puntos D, E y F, y sin dejar de oler las rosas o tener una taza de joe.

Una heurística es una técnica que te ayuda a buscar una respuesta. Sus resultados están sujetos al azar porque una heurística sólo te dice cómo mirar, no qué encontrar. No le dice cómo llegar directamente del punto A al punto B; Puede que ni siquiera sepa dónde están el punto A y el punto B. En efecto, una heurística es un algoritmo en un traje de payaso. Es menos predecible, es más divertido y viene sin una garantía de devolución de dinero de 30 días.

Aquí está un algoritmo para conducir a la casa de alguien: Tome la carretera 167 sur a Puyallup. Tome la salida South Hill Mall y conduzca 4,5 millas hasta la colina. Gire a la derecha en la luz de la tienda de comestibles, y luego tomar la primera a la izquierda. Gire en la entrada de la gran casa de color canela a la izquierda, en 714 North Cedar.

He aquí una heurística para llegar a la casa de alguien: Encuentre la última carta que le enviamos por correo. Conducir hasta la ciudad en la dirección de retorno. Cuando llegue a la ciudad, pregunte a alguien donde está nuestra casa. Todo el mundo nos conoce, alguien estará encantado de ayudarle. Si no puede encontrar a nadie, llámenos desde un teléfono público y nosotros le ayudaremos.

La diferencia entre un algoritmo y una heurística es sutil, y los dos términos se superponen algo. Para los fines de este libro, la principal diferencia entre los dos es el nivel de indirección de la solución. Un algoritmo le da las instrucciones directamente. Una heurística te dice cómo descubrir las instrucciones para ti, o al menos dónde buscarlas.

Tener direcciones que le dijeron exactamente cómo resolver sus problemas de programación sin duda haría la programación más fácil y los resultados más previsibles. Pero la ciencia de la programación todavía no es tan avanzada y nunca lo será. La parte más difícil de la programación es la conceptualización del problema, y ​​muchos errores en la programación son errores conceptuales. Debido a que cada programa es conceptualmente único, es difícil o imposible crear un conjunto general de instrucciones que conduzcan a una solución en todos los casos. Por lo tanto, saber cómo abordar los problemas en general es al menos tan valioso como saber soluciones específicas para problemas específicos.

¿Cómo se utilizan las metáforas del software? Úsalos para darte una idea de tus problemas y procesos de programación. Úsalos para ayudarte a pensar en tus actividades de programación y para ayudarte a imaginar mejores maneras de hacer las cosas. No podrá ver una línea de código y decir que viola una de las metáforas descritas en este capítulo. Con el tiempo, sin embargo, la persona que utiliza metáforas para iluminar el proceso de desarrollo de software será percibida como alguien que tiene una mejor comprensión de la programación y produce mejores códigos más rápido que las personas que no los utilizan.

Metáforas comunes del software

Una confusa abundancia de metáforas ha crecido alrededor del desarrollo de software. David Gries dice que el software de escritura es una ciencia (1981). Donald Knuth dice que es un arte (1998). Watts Humphrey dice que es un proceso (1989). P. J. Plauger y Kent Beck dicen que es como conducir un coche, aunque sacan conclusiones casi opuestas (Plauger 1993, Beck 2000). Alistair Cockburn dice que es un juego (2002). Eric Raymond dice que es como un bazar (2000). Andy Hunt y Dave Thomas dicen que es como cultivar un huerto. Paul Heckel dice que es como rodar Blancanieves y los siete enanitos (1994). Fred Brooks dice que es como cultivar, cazar lobos, o ahogarse con dinosaurios en un pozo de alquitrán (1995). ¿Cuáles son las mejores metáforas?

Software Penmanship: Escribiendo código

La metáfora más primitiva para el desarrollo de software surge de la expresión “escribir código”. La metáfora de la escritura sugiere que el desarrollo de un programa es como escribir una carta casual: se sienta con pluma, tinta y papel y escríbalo de principio a fin. No requiere ningún planeamiento formal, y usted figura hacia fuera qué usted quiere decir mientras que usted va.
Muchas ideas derivan de la metáfora de la escritura. Jon Bentley dice que usted debe ser capaz de sentarse junto al fuego con una copa de brandy, un buen cigarro, y su perro de caza favorito para disfrutar de un “programa alfabetizado” de la manera que sería una buena novela. Brian Kernighan y P. J. Plauger nombraron su libro de programación The Elements of Programming Style (1978) después del libro de escritura The Elements of Style (Strunk y White 2000). Los programadores suelen hablar de “programa legibilidad”.

Hard Data

Para el trabajo de un individuo o para proyectos de pequeña escala, la metáfora de escritura de cartas funciona adecuadamente, pero para otros propósitos deja la fiesta temprano, no describe el desarrollo de software de manera completa o adecuada. La escritura suele ser una actividad de una persona, mientras que un proyecto de software muy probablemente involucre a muchas personas con muchas responsabilidades diferentes. Cuando termine de escribir una carta, la envuelve en un sobre y la envía por correo. No se puede cambiar más, y para todos los efectos es completo. El software no es tan difícil de cambiar y casi nunca está completo. Hasta el 90 por ciento del esfuerzo de desarrollo en un sistema de software típico viene después de su lanzamiento inicial, con dos tercios siendo típicos (Pigoski 1997). En la escritura, una prima alta se pone en originalidad. En la construcción de software, tratar de crear un trabajo verdaderamente original es a menudo menos eficaz que centrarse en la reutilización de ideas de diseño, códigos y casos de prueba de proyectos anteriores. En resumen, la metáfora de la escritura implica un proceso de desarrollo de software que es demasiado simple y rígido para ser saludable.

Desafortunadamente, la metáfora de la escritura de cartas ha sido perpetuada por uno de los libros de software más populares del planeta, The Mythical Man-Month de Fred Brooks (Brooks 1995). Brooks dice: “Planee tirar uno lejos, usted lo hará, de todos modos.” Esto evoca una imagen de una pila de borradores medio escritos arrojados a una papelera, como se muestra en la Figura 2-1.

Figura 2-1. La metáfora de la escritura de la letra sugiere que el proceso del software confía en ensayo y error costosos más bien que planeamiento y diseño cuidadosos

Planear tirar uno lejos; Lo harás, de todos modos. -Fred Brooks

Si usted planea tirar uno lejos, usted lanzará lejos dos.-Craig Zerouni

Planear tirar uno lejos podría ser práctico cuando usted está escribiendo un educado cómo-hágalo usted-haga a su tía. Pero extender la metáfora del software de “escribir” a un plan para desechar uno es un mal consejo para el desarrollo de software, donde un sistema importante ya cuesta tanto como un edificio de oficinas de 10 pisos o un transatlántico. Es fácil agarrar el anillo de bronce si usted puede permitirse el lujo de sentarse en su pony de madera favorito para un número ilimitado de vueltas alrededor del carrusel. El truco es conseguirlo la primera vez-o tomar varias ocasiones cuando son más baratos. Otras metáforas mejor iluminan las maneras de alcanzar tales metas.

Cultivo de Software: Creciendo un Sistema

En contraste con la metáfora de la escritura rígida, algunos desarrolladores de software dicen que usted debe prever la creación de software como algo semejante a plantar semillas y cultivos. Usted diseña una pieza, codifica una pieza, prueba una pieza, y la agrega al sistema un poco a la vez. Al tomar pequeños pasos, minimizar el problema puede obtener en cualquier momento.

Punto ClaveA veces se describe una buena técnica con una mala metáfora. En tales casos, trate de mantener la técnica y llegar a una mejor metáfora. En este caso, la técnica incremental es valiosa, pero la metáfora agrícola es terrible.

 

Otras lecturas

Para una ilustración de una metáfora agrícola distinta, que se aplica al mantenimiento del software, véase el capítulo “Sobre los orígenes de la intuición del diseñador” en Repensar el análisis y el diseño de sistemas (Weinberg 1988).

La idea de hacer un poco a la vez podría tener algún parecido con la forma en que crecen los cultivos, pero la analogía agrícola es débil y poco informativa, y es fácil reemplazarla con las mejores metáforas descritas en las siguientes secciones. Es difícil extender la metáfora agrícola más allá de la simple idea de hacer las cosas un poco a la vez. Si usted compra en la metáfora de la agricultura, imaginada en la figura 2-2, podría encontrarse hablando acerca de la fertilización del plan del sistema, adelgazando el diseño detallado, aumentando los rendimientos del código a través de la gestión eficaz de la tierra y cosechando el código en sí. Hablaremos de rotación en una cosecha de C ++ en lugar de cebada, de dejar reposar la tierra durante un año para aumentar el suministro de nitrógeno en el disco duro.

Figura 2-2. Es difícil extender la metáfora agrícola al desarrollo de software de manera apropiada

La debilidad en la metáfora del cultivo de software es su sugerencia de que usted no tiene ningún control directo sobre cómo se desarrolla el software. Usted planta el código de semillas en la primavera. Almanaque del granjero y la Gran Calabaza dispuestos, tendrás una gran cosecha de código en el otoño.

Software tipo Agricultura de Ostras: Sistema de Acreación

A veces la gente habla sobre el crecimiento de software cuando realmente significan acreción de software. Las dos metáforas están estrechamente relacionadas, pero la acumulación de software es la imagen más perspicaz. “Acreción”, en caso de que no tengas un diccionario a mano, significa cualquier crecimiento o aumento de tamaño por una adición externa gradual o inclusión. Acreción describe la forma en que una ostra hace una perla, mediante la adición gradual de pequeñas cantidades de carbonato de calcio. En geología, “acreción” significa una adición lenta a la tierra por el depósito de sedimentos en el agua. En términos legales, “acreción” significa un aumento de la tierra a lo largo de las orillas de un cuerpo de agua por el depósito de sedimentos en el agua.

Esto no significa que usted tiene que aprender cómo hacer el código fuera del sedimento waterborne; Significa que usted tiene que aprender cómo agregar a sus sistemas de software una pequeña cantidad a la vez. Otras palabras estrechamente relacionadas con la acreción son “incremental”, “iterativo”, “adaptativo” y “evolutivo”. El diseño, la construcción y las pruebas incrementales son algunos de los conceptos de desarrollo de software más potentes disponibles.

 

Guardar

Leave a Comment

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">
*
*