péguelo las insertar etiquetas entre código codigo dry copy-paste

dry - las - insertar codigo adsense en wordpress



¿Por qué es peligroso copiar y pegar código? (18)

A veces, mi jefe se quejará con nosotros:

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

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

Realmente es 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?

¿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 compañía subestiman el tiempo necesario para completar algún proyecto. Y en base a una estimación errónea, se firmó un contrato, etc. En la mayoría de los casos, los programadores no participaron en las estimaciones.

¿Por qué sucede esto? A veces, el patrocinador del proyecto tiene un presupuesto demasiado pequeño. Tal vez un proceso comercial 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 una ilusión. 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 .

A mí me parece que la peor idea errónea que tu jefe no técnico tiene es que tu trabajo es predominantemente tipeado. Creen que puede ahorrar mucho tiempo al eliminar el tipeo.

Creo que la mejor educación que podría darle a esta persona es señalar todo el trabajo que hace que no está tipeando. Incluso si la mayor parte de ese trabajo generalmente ocurre de manera invisible, en tu cabeza, al mismo tiempo que se escribe.

Claro, eliminar el tipeo ahorrará tiempo. Pero luego, la parte mucho más grande de su trabajo, que no se escribe a máquina, se agranda y se consume más tiempo y más.

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

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

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

El código de diseño, copiado y pegado es ciertamente un desastre, con el potencial de causar muchos problemas en el futuro. Pero estás preguntando por qué te lleva mucho trabajo en este momento , la respuesta es: porque nunca es solo 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 y pegar, eso es usar una biblioteca de códigos. El código real de copiar y pegar suele ser más como este:

  • "¡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 mi fuente?"
  • "Hmmm, ¿qué hacen todas estas funciones ''util_func_023''? ¿No las documenté? ¿Cuáles de ellas necesito ahora?"
  • "Oh, sí, este código usa la Base de código Y. Supongo que necesito [ elegir uno: copiar toda la Base de código Y en mi nuevo proyecto / gastar un día en sacar la única función que quiero de Base de código Y / gastar una semana en liberar el una función que quiero de Code Base Y]. "
  • "¡Copié todo, yay!"
  • "¿Por qué no está funcionando?"
  • Este es el punto donde pasa horas / días / semanas depurando código existente que es similar a lo que desea, en lugar de escribir el código con el que realmente desea 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 un código similar. Ciertamente no se puede levantar completamente 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 manipular lo menos posible, incluso si se trata de una copia y no del original en sí.

Si desea basar su proyecto en copiar y pegar, primero tiene que codificar de una manera que permita una fácil reutilización, sin copiar el código original y sin jugar con él. Eso vale la pena hacerlo, y si eso es lo que su jefe está esperando, entonces los dos necesitan asegurarse de que así es como diseñan y trabajan en primer lugar.

El principio DRY (No repetir): DRY en wikipedia .

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

otro enlace

Hay ventajas y desventajas 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 del negocio, y solo pueden ser vistos por los desarrolladores.

Incluso si la otra aplicación ya tiene la función que necesita, es posible que el código de esa característica simplemente no se ajuste a su aplicación actual sin una reescritura importante. Es como tomar el motor de un Ford e intentar meterlo en un Toyota. En general, existe una regla general que indica 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 un sonido de biblioteca convincente, pero podría ser más difícil de lo que parece, dependiendo de cómo se construya ese otro sistema. Por ejemplo, el código de esa característica puede ser difícil de extraer porque interactúa con muchos otros códigos de maneras impuras (por ejemplo, accediendo a muchas variables globales, etc.)

La razón obvia es que asumes una ''deuda'' para el futuro: cualquier cambio que necesites hacer en el código (no solo correcciones de errores, cualquier cambio) ahora será el doble de caro porque tienes que actualizar dos lugares: y más arriesgado porque ALGUNO olvidará uno de ellos eventualmente. 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 de que "esto es lo mismo" suele sutilmente equivocarse. Siempre que su código dependa de suposiciones no dichas sea correcto, copiarlo en otro lugar da como resultado 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 siguiente cambio.

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

Luego, cuando una de las variantes pegadas tiene un problema, se modifica. 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 realmente jodido porque todas las áreas pegadas ya no son lo mismo.

Y no lo sabrías, este tipo de codificación de mierda casi siempre está vacía 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 tienes un código haciendo cada cosa en particular, entonces tienes un sistema.

Los comportamientos de un sistema se pueden cambiar con modificaciones de punto único 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.

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

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

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

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

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

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

Solo volvería a copiar y pegar código si tuviera la intención de refactorizarlo poco después, asegurándome de que luego extraje 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.

Si ya ha implementado las funciones y necesita copiar y pegar para volver a utilizarlas, parece que ha hecho algo mal. ¿No puedes poner estas características en una biblioteca para que puedas reutilizarlas sin copiarlas ni pegarlas?

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

Sin embargo, probablemente debas explicar que cada aplicación es diferente. Solo porque instaló una puerta en una casa no significa que pueda instalar otra puerta en otra casa en un abrir y cerrar de ojos : será más rápido debido a la experiencia (no tiene puertas instaladas), pero aún llevará tiempo obtener su equipo , monte la puerta, asegúrese de que esté a plomo y atorníllela al marco.

Trabajé para una compañía similar. Al ser un aprendiz, no lo sabía entonces, así que cuando comencé un nuevo proyecto, mi jefe también sugirió pegar el código en otro lugar. Bueno, como pueden pensar, todo el software fue un desastre, hasta el punto que cuando intentaron arreglar un error, aparecieron dos nuevos errores.

copiar y pegar es un desastre esperando que ocurra. Su jefe debe evaluar el precio de envío anticipadamente con respecto al precio de tener el código interrumpido enviado al usuario final muy pronto.

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