¿Cuál es una forma buena y concisa de explicar los peligros de la programación de copiar y pegar a los no programadores? [cerrado]

Estoy buscando una buena analogía o metáfora que pueda ilustrar los problemas de la programación de copiar y pegar a los no programadores. De vez en cuando hago revisiones de código / sistema para clientes potenciales, y uno de los problemas comunes que veo son grandes cantidades de código de copiar y pegar en todas sus bases de código. Es algo que rutinariamente menciono en las revisiones, y cada vez tengo que explicar por qué esto es un problema (esto es especialmente difícil con clientes que saben lo suficiente sobre programación para comprender que la reutilización es algo bueno, pero no lo suficiente para entender por qué copiar y pegar no es una buena forma de reutilización). Obviamente, puedo (y hago) explicar el problema en términos de mantenimiento de código, pero sería bueno tener una analogía buena y concisa para este problema que afectaría a los no programadores. Bonificación si la analogía ilustra por qué buscar y reemplazar no es una solución efectiva para este problema. ¿Alguna sugerencia?

Solo para aclarar (según la respuesta de Jaroslav a continuación): no estoy hablando de usar fragmentos de código aquí; lo que veo (inquietantemente a menudo) es copiar y pegar grandes extensiones de código, o un fragmento de código de diez líneas para obtener algunos datos del usuario (completos con consulta SQL en línea) pegados en docenas de páginas PHP o ASP.NET. Por lo tanto, duplica el código de otra parte del mismo proyecto.

Actualización: hay varias respuestas realmente buenas aquí; He explicado en los comentarios por qué elegí la respuesta de Scott Whitlock, pero también recomendaría altamente la respuesta de whatsisname si se trata de clientes que están familiarizados con la fabricación.

Es así ... tienes un reloj en tu casa. ¡Excelente! Sabes qué hora es, pero siempre tienes que ir a esa habitación para verlo.

Pero, por supuesto, desea saber qué hora es sin ir a esa habitación todo el tiempo, por lo que compra algunos relojes más y los distribuye por su casa. Cada uno de estos relojes es independiente. Todos mantienen su propio tiempo. Esto significa:

• Cuando el horario cambia debido al horario de verano, debe cambiarlos todos
• Incluso cuando están listos, todos son un poco diferentes y rara vez coinciden perfectamente. Con el tiempo van a la deriva.

Ahora imagine el mismo problema en una instalación grande con docenas o cientos de relojes. Es por eso que necesita algo como este reloj en red que se mantiene sincronizado con una base de tiempo central. De esa manera, el tiempo se define una vez y solo una vez .

La programación de copiar y pegar es como comprar relojes más independientes. No escala

Imagina que estás diseñando un avión. Tienes un solo motor a reacción. Se vende bien. Ahora vas a diseñar un avión de 4 motores para largas distancias a través del océano.

Ahora, no crea un conjunto completo de especificaciones de ingeniería y dibujos para cada motor individual, ¿verdad? No, usas el mismo motor en los cuatro lugares. Ahora imagine si tuviera 4 juegos de dibujos y tuviera que cambiar algo. Ahora debe cambiarlo en los cuatro dibujos del motor. ¿Qué sucede si accidentalmente olvida cambiar algo en el cuarto motor porque estaba espaciando?

Digamos que está cambiando la longitud de un tornillo o una rosca de tubería. Ahora no puede simplemente "buscar y reemplazar" en su base de datos de dibujos de ingeniería, podría cambiar accidentalmente los tornillos de montaje en las bombas de combustible porque eran del mismo tamaño. O la línea hidráulica que acciona el timón de cola usaba el mismo hilo, pero ahora es diferente y ya no puede alimentar la cola.

Ahora imagina que te molesta la NTSB porque tus motores arrojan aletas de turbina al azar y explotan mientras vuelas al sur de Florida. ¿Ahora qué dibujos de motor miras? ¿Todos ellos, uno de ellos? ¿Cómo sabes que los cuatro son iguales? Tal vez las correcciones se hacen, pero solo se aplican al motor uno, porque el tipo que diseñó los motores dejó un año atrás para tocar en una banda de reggae y fue el único que recordó que los cuatro motores están en archivos separados, y el El tipo que arregló la explosión de la turbina fue su reemplazo.

Copiar y pegar código es análogo a tener dibujos duplicados de componentes, ya sea un tornillo o un motor. Desea resumir los componentes en piezas fundamentales que se reutilizan tanto como sea posible.

No duplique los motores, solo escriba el código que los monta en el ala.

Tiene que explicarlo en términos de compartir el mismo recurso versus duplicar el mismo recurso.

Por ejemplo, ¿tendría sentido que cada casa en una gran ciudad tenga una estación de energía dedicada que suministre electricidad a la casa o tendría más sentido que cada casa comparta la misma estación de energía? Si algo sale mal con un componente en particular utilizado en la (s) estación (es) eléctrica (s) y se requieren reparaciones, sería más fácil hacer las reparaciones en un solo lugar y todos se beneficiarían de estas reparaciones en lugar de hacer las reparaciones en cada estación eléctrica dedicada y solo en cada Beneficios de la casa individualmente.

"Oye, mira, ¿ toda la cirugía es algo similar, verdad? ¿Entonces no te importaría si copio al azar las instrucciones quirúrgicas para diferentes procedimientos de diferentes cirujanos para tu operación?"

Copiar y pegar es como tratar de fabricar piezas sin molde. Es lento, y obtendrá un uso único de cada parte, ya que una vez que se determina que está defectuoso o roto, no puede simplemente arreglar el molde para crear un reemplazo adecuado.

En la búsqueda de una analogía, primero tenemos que considerar los peligros de la programación de copiar y pegar :

• Errores introducidos porque la copia no se ajusta exactamente (variables innecesarias y rutas de código no limpiadas)
• Mayores requisitos de prueba : la abstracción ayuda a eliminar la necesidad de pruebas de regresión, ya que solo prueba lo que ha cambiado y solo cambia las hojas, no las ramas.
• La duplicación duplica todo, errores incluidos. Cada corrección de error o característica que se aplica a ambas secciones del código ahora cuesta el doble de implementación y existe una alta probabilidad de olvidarlo por completo.
• Buscar y reemplazar exacerba el problema anterior, ya que no puede encontrar fácilmente el código duplicado.

El arma principal en la lucha contra la programación de copiar y pegar es la abstracción . Entonces, para encontrar una buena analogía, busque ejemplos de abstracción en el mundo que nos rodea.

La abstracción se basa en la idea de establecer definiciones y luego proceder a usar esas definiciones en la ejecución. ¿Cómo sería el mundo sin definiciones?

• Las definiciones son una parte clave del lenguaje legal. Imagine un contrato que no tenía definiciones centrales pero que definía completamente cada término cada vez que se usaba.
• Las definiciones y plantillas se utilizan en la construcción. Un problema común en la construcción es hacer cada nuevo corte basado en el último en lugar de en una sola medición tomada al principio. Esto puede dar lugar a longitudes muy diferentes con el tiempo.
• La organización de la empresa se basa en resúmenes y definiciones. ¿Qué pasaría si cada vez que su empresa tuviera que expandirse, tuvieran que definir el nuevo rol desde cero? Eso no funcionaría. Entonces, ¿qué pasa si deciden elegir un puesto de trabajo similar y modificarlo ligeramente para adaptarlo? Todos estarían encerrados en su lugar porque sería imposible mover recursos.

La copia solo tiene un lugar cuando la pieza que se copia es permanente. De lo contrario, cada copia crea una rama completamente nueva para ser tratada: probada, mantenida y actualizada por separado.

La abstracción combate esto atando todas las ramas en un solo tronco y aislando las modificaciones en ramas más pequeñas o incluso en hojas.

Creo que estás hablando de código duplicado, no de copiar y pegar (usando fragmentos y similares).

Aquí hay una analogía de un libro de historia, que lo ilustra muy bien. Antes de la prensa de Gutenberg, los monjes estaban sentados y escribiendo los libros a mano y reescribiendo el mismo libro una y otra vez. Los libros que escribieron los monjes, a menudo tenían errores y gracias a Gutenberg este problema fue eliminado.

Otra analogía: cajeros automáticos. Tiene un cajero automático que puede servir varias tarjetas y siempre las sirve bien. La duplicación del código crea diferentes cajeros automáticos, por lo que todos tendrían que ir a uno diferente y, a veces, la máquina incluso le daría un BSOD.

Hay un impresionante artículo sobre el pegado de copias de Jeff http://www.codinghorror.com/blog/2009/04/a-modest-proposal-for-the-copy-and-paste-school-of-code-reuse. html

PD: Sé que hubo una imprenta antes de Gutenberg.

Para los no programadores, supongo que estamos hablando de gente de negocios, por lo que sería breve e involucraría las realidades del dinero.

1. Cada línea de código le cuesta dinero (ya sea escrito o copiado)
2. Cada error te cuesta mucho más que cada línea.
3. Cada línea de código agrega errores potenciales
4. Código duplicado = errores duplicados
5. Los errores duplicados casi nunca se encuentran en el mismo ciclo de prueba.

Cortar y pegar = Quemar dinero.

¿No puedo responder la pregunta pero decir que realmente no necesitas una analogía aquí, y tratar de encontrar la analogía correcta para cada modismo o patrón de desarrollo parece perverso y a menudo es contraproducente? Es como tratar de hacer yoga con los pies planos ...

Hay algunas razones por las cuales copiar / pegar conduce a problemas, propaga errores existentes en áreas recién pegadas, en algunos entornos donde solía considerarse una mejora del rendimiento, en realidad ahora es más lento (puedo proporcionar ejemplos si alguien está interesado, pero todo se reduce a JIT y ¿realmente crees que eres más inteligente que un compilador moderno?

Muestra que el desarrollador es perezoso o egoísta o ambos. Si esta es una batalla en la que estás luchando en un equipo en este momento, dependiendo de tu posición en este equipo (líder del equipo / jnr dev, snr dev, lo que sea) necesitas arreglarlo, posiblemente mediante arbitraje dentro de tu organización.

EDITAR: a la luz del comentario a continuación, que este es un código que revisa el código de un tercero en nombre del tercero (o tal vez incluso de un cuarto :)) Hay algunas cosas útiles que puedo agregar con suerte.

Primero, cuando se produjo el código para el tercero, ¿tenían alguna métrica? Líneas de código (LoC) por ejemplo.

Todavía creo que algo de lo que dije arriba todavía cuenta. Probablemente también debería haber preguntado cuál era el objetivo de la revisión. Si desea obtener una cotización para mantenerla o reemplazarla, debe hacer muchas preguntas diferentes.

De cualquier manera, está evaluando la calidad del código, bueno, copiar cualquier pegado cae en la categoría de "El desarrollador mostró una comprensión adecuada del diseño de abstracción y / o control de flujo del programa":

Comentario: El desarrollador no pudo mostrar ninguna comprensión de la abstracción, y su enfoque para el control del flujo del programa era propenso a errores. Puede introducir "Complejidad ciclomática" aquí. En realidad es bastante fácil de entender, y creo que podría haber encontrado una respuesta: D Sí por mí.

Ok La complejidad ciclomática es así. Tienes un mapa Tiene su posición de inicio y todos los destinos posibles. No tiene que ser mucho. Piensa, aparcamiento, cafetería, baño. La complejidad ciclomática es una medida del número de rutas diferentes que hay para llegar a su posición de inicio a cualquiera de los destinos.

El código copiado y pegado probablemente aumentará la complejidad ciclomática porque incluirá lógica repetida que podría haberse resumido en su propio bloque (o método) con nombre.

Parece razonable?

Toma una palabra en inglés para algo. Ahora imagine que cada vez que desea describir esa cosa, utiliza la definición completa del diccionario en lugar de solo la palabra. ¿Qué tan fácil sería para los demás entenderte?

Yo formar una imagen mental de algo que no está presente o que no es el caso (imaginar) que Indicando una acción o estado que está condicionada a otra; Pasado simple de voluntad. Indicando el futuro relativo a un tiempo pasado. Indicar una acción en el pasado que sucedió repetidamente o comúnmente (sería) no sería fácil; que requiere un gran esfuerzo físico o mental para lograr o comprender o soportar (difícil).

Tampoco estaría de más mostrar un ejemplo real de antes y después del código real que se ha refactorizado para eliminar la duplicación.

También hay problemas de seguridad e integridad del código.

Como se demostró aquí , es posible incrustar datos maliciosos en caracteres Unicode que se transfieren al portapapeles.

Dependiendo de cómo responda su editor a los caracteres Unicode, esto puede ocasionar cambios inesperados en su código fuente, salidas inesperadas del compilador o algunas cosas que aún no he pensado.

Hay un par de rutas diferentes que podría ver tomando aquí:

1. Plagio : algunos pueden recordar esto de la escuela donde el robo de propiedad intelectual es un gran no-no. La programación de copiar y pegar puede ser así, ya que es posible que alguien no entienda la fuente o qué problemas puede surgir del uso de una solución particular que se copió y pegó a ciegas sin analizar qué tan bien funciona y entender por qué esto puede o no ser Una solución efectiva al problema.

2. Seguir instrucciones a ciegas: la mayoría de las personas probablemente habrían tenido experiencias para llegar a algún lugar en el que no hayan estado anteriormente. Algunos pueden haber usado MapQuest o Google Maps para encontrar un lugar y luego seguir las instrucciones dadas. Ha habido historias de personas que se pierden o simplemente no encuentran dónde se supone que deberían estar, a pesar de que el software dio instrucciones específicas sobre cómo llegar allí. Este es el otro gran peligro de copiar y pegar: es como si alguien le hubiera dado las instrucciones para ir de A a B sin permitirle ver ningún mapa del área que pueda dificultar un viaje. Si eso no parece difícil, podría subir la apuesta pidiéndole a la persona que vaya de A a B con los ojos vendados para que tengan que confiar en otros sentidos para determinar en qué dirección están mirando y llegar a un objetivo.

Los datos, la información, el conocimiento y la sabiduría pueden ser un buen modelo al que se podría hacer referencia para mostrar por qué buscar y reemplazar no es efectivo como solución porque copiar y pegar es muy mecánico y sin pensar mucho, por lo que los datos transferidos pueden ser sin el conocimiento y la sabiduría de usarlo adecuadamente. Uno podría mirar la energía nuclear para ver ejemplos de cómo comprender la diferencia puede ser bastante poderoso. Contraste un reactor nuclear con una bomba nuclear en términos de seguridad y utilícelo para ver cómo saber exactamente qué va a dónde no es suficiente para aprovechar de forma segura el poder del átomo.

Imagina que tienes un grupo de estudiantes y un conjunto de reglas para la escuela. En lugar de publicar las reglas en un lugar común, todos los estudiantes deben hacer referencia a usted y entregar a cada uno una copia de las reglas. A cada estudiante se le dice que debe seguir su copia de las reglas al pie de la letra.

Ahora modifique una de las reglas diciendo que en el caso de un desastre debe ir al nuevo refugio para desastres. Tienes que ir a cada estudiante y modificar su conjunto de reglas. Si uno de los estudiantes se pierde y un tornado golpea, el estudiante irá al lugar anterior y morirá de una muerte horrible.

Alguien le envía un correo electrónico con una plantilla de documento adjunta. Siéntase libre de seguir usándolo hasta que cambie la plantilla. No se preocupe, no se olvidarán de enviarle una copia actualizada.

El modelo de costos CoCoMo.

http://en.wikipedia.org/wiki/COCOMO

Esfuerzo aplicado (E) = a * (KLOC) ** b, donde b> 1.0

Ese exponente significa que el esfuerzo para construir / mantener / apoyar / reescribir crece más rápido que el número de líneas de código.

Hay otro aspecto importante de esta mala práctica que nadie tuvo en cuenta todavía: al copiar ciegamente (total o parcialmente) el código de otra persona ( sin su permiso ) , podría estar infringiendo las leyes de derechos de autor .

La codificación de copiar y pegar que veo es una en la que el desarrollador no entiende o no quiere razonar lo que están haciendo, y copia juntas diferentes partes que ya hacen "más o menos" lo que necesitan, moviéndolas al azar al final para que encajen juntos.

Hay tres problemas principales con eso:

1. Nunca da como resultado un código libre de errores. Siempre.
2. Si no entendieron el código mientras lo escribían, nunca podrían descifrarlo durante la depuración. Solo alguien más puede limpiar el desorden que hicieron, a un costo adicional.
3. Si evitan pensar en el código que están escribiendo, evitan aprender. Si evitan aprender, nunca serán buenos programadores. Si nunca van a ser un buen programador, ¿por qué están en su equipo?

Digamos que tienes 5 novias (eres un perro astuto) y deseas enviarles un mensaje de San Valentín. Escribe la primera letra, agrega su nombre y menciona algo memorable que ustedes compartieron. Luego copie y pegue la carta cuatro veces, cada vez que pierda una instancia del nombre de la novia # 1 con copiar y pegar porque cometió un error tipográfico. Ahora, 4 de tus cinco novias se dirigen a la casa de la novia # 1.