¿Por qué es peligroso "copiar y pegar" el código? [cerrado]

A veces, mi jefe se queja con nosotros:

¿Por qué necesitamos tanto tiempo para implementar una función?

En realidad, la función se ha implementado en otra aplicación anteriormente, solo necesita copiar y pegar códigos desde allí. El costo debe ser bajo.

Es realmente una pregunta difícil, porque copiar y pegar códigos no es algo tan simple en mi punto de vista.

¿Tiene alguna buena razón para explicar esto a su jefe no técnico?

Si encuentra un error en su código de copiar y pegar, deberá repararlo en cada lugar que lo hizo y esperar que pueda recordarlos a todos (esto también es válido para los requisitos modificados).

Si mantiene la lógica en un lugar, es más fácil cambiarla cuando sea necesario (por lo tanto, si decide que la aplicación necesita actualizarse, solo lo hace en un lugar).

Haga que su jefe lea sobre el principio DRY (no se repita).

Lo que está describiendo suena como el uso perfecto para bibliotecas , donde comparte código y solo lo mantiene en un lugar.

Solo copiaría y pegaría código si tuviera la intención de refactorizarlo poco después, asegurándome de extraer el código común para poder reutilizar la mayor cantidad de lógica posible. Y poco después, quiero decir minutos y horas después, no días y semanas.

Sería mucho mejor compartir el código construyendo una biblioteca en lugar de copiar el código usando copiar y pegar.

Aún obtendrá una ventaja de velocidad sobre la reescritura (buscar DRY) pero solo tendrá un lugar para mantener el código.

La razón obvia es que asume una 'deuda' para el futuro: cualquier cambio que necesite hacer en el código (no solo las correcciones de errores, cualquier cambio) ahora será el doble de costoso porque tiene que actualizar dos lugares: y más arriesgado porque eventualmente olvidarás uno de ellos. En otras palabras, hacer que funcione más rápido ahora hará que su trabajo sea aún más lento en el futuro, lo que puede ser un buen sentido comercial pero generalmente no lo es.

Pero la razón más importante es que la suposición "esto es lo mismo que eso" es a menudo sutilmente errónea. Siempre que su código dependa de suposiciones tácitas para ser correcto, copiarlo en otro lugar produce errores a menos que estas suposiciones también se mantengan en el nuevo lugar. Por lo tanto, el código pegado a menudo es incorrecto desde el principio y no solo después del próximo cambio.

El código de diseño y copiado es ciertamente un desastre, con el potencial de causar muchos problemas en el futuro. Pero estás preguntando por qué se tarda mucho trabajo en este momento , la respuesta es: porque está nunca se acaba de copiar y pegar.

Si el código original fue escrito para ser reutilizado, como una biblioteca bastante independiente, con flexibilidad y uso del cliente en mente, entonces genial, pero eso no es copiar, pegar, es usar una biblioteca de códigos. Copiar y pegar el código real suele ser más o menos así:

• "Claro, ¡ya tengo un código que hace exactamente eso!"
• "Espera, ¿cuál de estas cinco versiones de código es la que quiero usar como fuente?"
• "Hmmm, ¿qué hacen todas estas funciones 'util_func_023'? ¿No las documenté? ¿Cuál de ellas necesito ahora?"
• "Oh, sí, este código usa Code Base Y. Supongo que necesito [ elegir uno: copiar todo Code Base Y en mi nuevo proyecto / pasar un día sacando la única función que quiero de Code Base Y / pasar una semana sacando el una función que quiero de Code Base Y] ".
• "¡Copié todo, yay!"
• "¿Por qué no funciona esto?"
• Este es el punto en el que pasa horas / días / semanas depurando el código existente que es similar a lo que desea, en lugar de escribir el código con el que realmente quiere comenzar.

En resumen, el código existente que no se puede usar directamente puede, en el mejor de los casos, servir como una buena referencia para escribir código similar. Ciertamente no se puede levantar por completo y se espera que funcione en un sistema completamente diferente. En general, es una suposición segura de que cualquier código que se haya escrito y completado se debe confundir con la menor cantidad posible, incluso cuando se trata de una copia y no del original en sí.

Si desea basar su proyecto en copiar y pegar, debe comenzar con el código de una manera que permita una fácil reutilización, sin copiar ese código original y perder el tiempo con él. Vale la pena hacerlo, y si eso es lo que su jefe espera, entonces ambos deben asegurarse de que así es como diseñan y trabajan en primer lugar.

copiar y pegar es un desastre a la espera de suceder. Su jefe debe evaluar el precio del envío temprano con respecto al precio del envío del código roto al usuario final muy pronto.

Si ya ha implementado las funciones y necesita copiar y pegar para reutilizarlas, parece que ha hecho algo mal. ¿No puede poner estas características en una biblioteca para poder reutilizarlas sin copiar / pegar?

El principio DRY (No te repitas): DRY en wikipedia .

"Cada pieza de conocimiento debe tener una representación única, inequívoca y autorizada dentro de un sistema".

Otro enlace .

Me parece que el peor error que tiene su jefe no técnico es que su trabajo es predominantemente escribir. Piensan que puede ahorrar mucho tiempo al eliminar la escritura.

Creo que la mejor educación que le puedes dar a esta persona es señalar todo el trabajo que haces que no está escribiendo. Incluso si la mayor parte de ese trabajo generalmente ocurre de manera invisible, en su cabeza, al mismo tiempo que escribe.

Claro, eliminar la escritura ahorrará algo de tiempo. Pero luego, la parte de tu trabajo, mucho más grande y sin tipeo, se hace más grande y consume tiempo y más.

¿Estás seguro de que tu jefe quiere saber sobre el principio DRY, los errores y otras cosas tecnológicas?

Ese tipo de comentarios que suele escuchar cuando su jefe o empresa subestiman el tiempo necesario para completar algún proyecto. Y basado en una estimación incorrecta, se firmó un contrato, etc. En la mayoría de los casos, los programadores no participaron en las estimaciones.

¿Por qué pasa esto? A veces el patrocinador del proyecto tiene un presupuesto demasiado pequeño. Tal vez un proceso de negocio que esté automatizando usando software no valga el esfuerzo de su equipo. Los gerentes generalmente tienden a estar muy cerrados por las malas noticias en tales casos. Al comienzo del proyecto hay ilusiones. Entonces los gerentes intentan culpar a los programadores. En su caso indirectamente a través de copiar y pegar. En casos extremos, esto se llama marcha de la muerte .

Copiar y pegar código generalmente conduce a la programación por coincidencia

Creo que " otra aplicación " es clave aquí, si la otra aplicación ya está probada y en uso, no debe cambiarse para usar una biblioteca común, por lo tanto, no puede compartir código con ella.

Dentro de la misma aplicación , "copiar y pegar" es malo, pero entre las bases de código desarrolladas por diferentes equipos o con diferentes ciclos de lanzamiento, "copiar y pegar" puede ser la mejor opción.

Trabajé para una empresa similar. Como aprendiz, no lo sabía mejor, así que cuando comencé un nuevo proyecto, mi jefe también sugirió pegar el código desde otro lugar. Bueno, como puede pensar, todo el software fue un desastre, hasta el punto de que cuando trató de corregir un error, aparecieron dos nuevos errores.

Incluso si la otra aplicación ya tiene la característica que necesita, el código para esa característica podría simplemente no encajar en su aplicación actual sin una reescritura importante. Es como tomar el motor de un Ford e intentar encajarlo en un Toyota. En general, existe una regla general de que si tiene que modificar más del 25% del código que copia, es mejor (más barato) reescribirlo desde cero.

Extraer el código en cuestión en una biblioteca suena convincente, pero puede ser más difícil de lo que parece, dependiendo de cómo esté construido ese otro sistema. Por ejemplo, el código para esa característica puede ser difícil de extraer porque interactúa con muchos otros códigos de formas no limpias (por ejemplo, al acceder a muchas variables globales, etc.)

Dígale a su jefe que la parte del nombre de todas y cada una de las variables incluye el nombre del proyecto anterior y ahora debe cambiarlas todas manualmente. Si su jefe no sabe (o quiere saber) por qué copiar / pegar es malo, él / ella también podría creer eso :)

Sí, el mayor problema es que no se trata solo de copiar y pegar, sino de copiar, pegar y luego modificar ligeramente.

Luego, cuando una de las variantes pegadas tiene un problema, se cambia. Luego, más tarde, se cambia otra variante.

Luego, descubres que todas las variantes tienen que cambiar porque la copia original tenía errores. Ahora estás bien y realmente jodido porque todas las áreas pegadas no son las mismas.

Y no lo sabrías, este tipo de codificación de mierda generalmente está casi libre de comentarios.

Para mí, la diferencia es que cuando tienes varias copias de código haciendo lo mismo, lo que tienes es un montón de código. Cuando solo tiene una pieza de código haciendo cada cosa en particular, entonces tiene un sistema.

Los comportamientos de un sistema se pueden cambiar con modificaciones de un solo punto con bastante facilidad: cambiar el comportamiento de un montón de código requiere un montón de código.

Me gustan los sistemas, no un montón de código.

Existen compensaciones entre la velocidad de desarrollo de la funcionalidad inmediata frente a usted (especialmente cuando la aplicación es pequeña) y los costos de mantenimiento a más largo plazo a medida que la aplicación crece.

Copiar y pegar es más rápido para la funcionalidad inmediata, pero le costará caro a medida que la aplicación crece en tamaño, en términos de corregir errores y realizar cambios en todo el sistema y mantener los flujos de trabajo entre los diferentes componentes de la aplicación.

Ese es el argumento que los dueños de negocios necesitan escuchar. Es similar a los costos aceptados de mantener una flota de vehículos, sin embargo, con el software, los aspectos rotos de la arquitectura del software generalmente están ocultos para el lado comercial, y solo los desarrolladores pueden verlos.

Tiene razón en que si el equipo ha implementado una funcionalidad similar antes, repetirlo será mucho más fácil la segunda vez.

Sin embargo, probablemente debería explicar que cada aplicación es diferente. El hecho de que haya instalado una puerta en una casa no significa que pueda instalar otra puerta en otra casa en muy poco tiempo : será más rápido debido a la experiencia (# puertas instaladas), pero aún le llevará tiempo conseguir su equipo , monte la puerta, asegúrese de que esté a plomo y atorníllela en el marco.

En mi empresa, siempre trabajamos con clases y métodos, y hacemos documentación técnica para ellos. Creo que es la mejor práctica si puede usar sus propias aplicaciones de búsqueda svn con buenas claves para encontrar la clase de método utilizada antes :)