¿Cómo se llama el antipatrón opuesto a "reinventar la rueda"? [cerrado]


101

El antipatrón " Reinventar la rueda " es bastante común: en lugar de usar una solución lista, escriba la suya desde cero. La base de código crece innecesariamente, las interfaces ligeramente diferentes que hacen lo mismo pero abundan de manera ligeramente diferente, se pierde tiempo para escribir (¡y depurar!) Funciones que están fácilmente disponibles. Todos lo sabemos.

Pero hay algo en el extremo opuesto del espectro. Cuando, en lugar de escribir su propia función que son dos líneas de código, importa un marco / API / biblioteca, lo instancia, configura, convierte el contexto al tipo de datos como lo acepta el marco, luego llama a esa única función que hace exactamente lo que necesita, dos líneas de lógica de negocios bajo un gigabyte de capas de abstracción. Y luego debe mantener la biblioteca actualizada, administrar las dependencias de compilación, mantener las licencias sincronizadas, y su código de instancia es diez veces más largo y más complejo que si simplemente "reinventara la rueda".

Las razones pueden ser variadas: la administración se opone estrictamente a la "reinvención de la rueda" sin importar el costo, alguien impulsando su tecnología preferida a pesar de la superposición marginal con los requisitos, una función cada vez menor de un módulo anteriormente importante del sistema, o la expectativa de expansión y mayor alcance uso del marco, que nunca llega, o simplemente malinterpreta el "peso" que un par de instrucciones de importación / inclusión / carga llevan "detrás de escena".

¿Existe un nombre común para este tipo de antipatrón?

(No estoy tratando de comenzar una discusión cuando está bien o mal, o si es una verdadera antipatrón o algo basado en una opinión , esta es una pregunta simple y directa de la nomenclatura objetiva).

Editar: el "duplicado" sugerido habla sobre la ingeniería excesiva del propio código para que esté "listo para todo", completamente aparte de los sistemas externos. En ciertos casos, esto podría deberse a ello, pero en general se origina en la "aversión a reinventar la rueda": la reutilización del código a toda costa; Si existe una solución "lista para usar " para nuestro problema, la usaremos, sin importar cuán mal se ajuste y a qué costo. Favoreciendo dogmáticamente la creación de nuevas dependencias sobre la duplicación de código, sin tener en cuenta los costos de integración y mantenimiento de estas dependencias en comparación con el costo de creación y mantenimiento del nuevo código.


52
Dependencia del infierno . Eso es lo más cerca que puedo pensar.
Machado

55
@Machado: Bien, aunque yo diría que Dependency Hell es el resultado directo de la abundancia de este antipatrón; en el caso de sistemas extremadamente complejos, puede ser un resultado directo de la complejidad.
SF.

27
Yo lo llamaría análogo de "arrastre de dependencia" a Feature_creep o Scope_creep, donde se agregan cada vez más características originalmente no deseadas al producto.
k3b

21
El fiasco de la almohadilla izquierda es un ejemplo real de este síndrome en acción.
SF.

13
Recomiendo que comencemos colectivamente a referirnos a esto como LeftPad.
RubberDuck

Respuestas:


9

No. No existe un nombre antipatrón de uso común que cubra lo que está describiendo.


44
Aparece con la cantidad de ideas, sugerencias y discusión que despertó, esto es realmente correcto.
SF.

3
Me siento sucio haciendo esto.
SF.

¿Eh? "No hay XXX" es una declaración muy fuerte y muy difícil de probar, especialmente considerando que hay varios candidatos mencionados en los comentarios.
AnoE

1
@AnoE "¿Hay un nombre común para este tipo de antipatrón?" La evidencia en dichos comentarios y respuestas implica en gran medida que no existe. Es cierto que no responde el título, pero responde la pregunta en sí.
Kroltan

@AnoE No puedes probar un negativo, cariño. ¿Quizás el término se esconde debajo de una roca en algún lugar de Borneo y todavía no nos hemos caído? Que hay 10 respuestas en lugar de 1 con un millón de votos a favor es prueba suficiente para mí.

49

Martillo de oro

El martillo dorado es una herramienta elegida solo porque es elegante. No es rentable ni eficiente para realizar la tarea prevista.

fuente: xkcd 801

(A pesar de los votos negativos, mantengo esta respuesta. Puede que no sea exactamente lo contrario de reinventar la rueda semánticamente, pero se ajusta a todos los ejemplos mencionados en la pregunta)



3
Votaría en contra de esto si tuviera el representante. No responde la pregunta en su conjunto, pero ofrece un término (exacto) que responde solo a uno de los escenarios sugeridos.
David

3
Se pidió lo contrario. Esto es como insistir en que "Becquerel" (radiación, unidad es s ^ -1) puede usarse para música en lugar de Hertz (hz, unidad es s ^ -1) porque ambos significan "por segundo".
Thorbjørn Ravn Andersen

@ ThorbjørnRavnAndersen He escuchado música muy peligrosa en mi día.

34

Robert Martin usa el término " Framework Bound " para referirse a la consecuencia negativa más obvia de este antipatrón. Como no creo que haya un nombre común para el patrón en sí, una referencia a esta consecuencia podría ser suficiente para la mayoría de los propósitos.


1
Existen marcos para acelerar el proceso de desarrollo. Son como un cohete de refuerzo: se gastan tan pronto como se usan. La solución es: la versión de lanzamiento uno, ahora ¿dónde estábamos? Así es, desarrollar software. ¡Siguiente! El mantenimiento es una preocupación separada, y creo que no debería ser importante en estos días. Lleve el siguiente marco a la siguiente solución, post prisa.

18

Esta página de Wikipedia en " Inventado aquí " describe una situación ligeramente diferente pero con resultados finales muy similares. Describe la aversión de un equipo hacia la creación de su propio código cuando se puede encontrar una funcionalidad equivalente.

Sin embargo, diría que el nombre es un poco engañoso. Tiene sentido cuando se pone en contexto con su opuesto No inventado aquí, lo que en mi humilde opinión es prácticamente un sinónimo de reinventar la rueda.


13

He escuchado " Buy Versus Build " e " Invented Here " como nombres antipatrón para un sesgo en contra de desarrollar cosas internamente, incluso cuando tenga sentido hacerlo. (Y aunque se supone que la frase "comprar versus construir" indica una elección entre alternativas viables, creo que generalmente se menciona cuando alguien cree que "comprar" es la opción correcta).



8

La hinchazón es un término amplio, pero puede incluir lo que usted describe. Nuestro software se vuelve demasiado complejo (hinchado) debido a todas las transformaciones y abstracciones adicionales requeridas, y tanto la complejidad como las dependencias mismas contribuyen a un menor rendimiento / menos eficiencia y un mayor consumo de recursos (disco, ancho de banda).

Si lo deseamos, podríamos aclarar con un término como dependencias hinchadas .


5

Creo que usar un mazo para romper una nuez está bastante cerca. Es algo que es posible, pero necesita una cantidad excesiva de trabajo para romper una tuerca de esa manera, sin que ocurra ninguno de los numerosos efectos secundarios no deseados posibles. (Y hay una bolsa entera de nueces para romper ...)

La frase también tiene la ventaja de que no es jerga informática, por lo que puede ser muy útil para transmitir una pista a alguien que no tiene ninguna.

Por cierto, hay que hacer una distinción con el infierno de la dependencia . Si alguien ya ha incluido todas las complejidades dentro de una encapsulación que crea interfaces simples, claras y fáciles de usar, y siempre que la penalización en los ciclos de la CPU o el uso de la memoria no sea excesiva, y siempre que sea poco probable que se produzca una futura modificación del código encapsulado es necesario, entonces un argumento restante en contra de usarlo es el infierno de dependencia que podría estar causando.


5

No creo que haya un análogo exacto, pero diría que el diseño excesivo o la ingeniería excesiva se acercan más.

Al menos, diría que esto es lo que realmente estaba sucediendo cuando me encontré con algo similar a lo que usted describe.

Usar una biblioteca en lugar de escribir su propio código para implementar la misma funcionalidad casi nunca es dañino.

Incluso en su ejemplo hipotético, puede que no sea necesario usar una biblioteca para reemplazar "dos líneas de código", pero es poco probable que le cause mucho dolor, si realmente es una biblioteca destinada a hacer lo mismo que sus dos líneas de código .

Una biblioteca para hacer algo simple también será simple. No es probable que te dé los dolores de cabeza que implica tu pregunta.

Usar una biblioteca complicada para hacer algo simple probablemente implica que está tratando de hacer más que implementar la funcionalidad requerida.

Como construir características que no son necesarias, prepararse para un futuro que nunca llegará, etc.

El problema aquí no es realmente no reinventar la rueda per se .


4

Si no ha reinventado la rueda, lo más probable es que esté utilizando un juego de ruedas existente proporcionado por un proveedor o un tercero.

Si se trata de un antipatrón, generalmente se denomina bloqueo de proveedor.


66
Realmente no siento que sea lo mismo. El bloqueo del proveedor es un resultado negativo particular de depender de la solución de un proveedor, ya sea que el uso del proveedor sea rentable o no cuando se hizo la elección. El OP pregunta más sobre un término para elegir una solución de terceros cuando el costo de integración es más alto que el costo de simplemente desarrollar una nueva solución desde cero (y el bloqueo del proveedor probablemente ni siquiera esté ocurriendo, en los casos en que ser barato para desarrollar una nueva solución en lugar de depender del proveedor).
Ben

@Ben - Ok, me gusta el marco vinculado en lugar del bloqueo del proveedor mejor. Esta pregunta está basada en una opinión y esto fue lo primero que se me ocurrió.
Jon Raynor

0

¿Seguridad en el empleo?
Usted menciona todo el esfuerzo de mantener las cosas sincronizadas, etc. Algunas personas prefieren administrar el código de otras personas que escribir el suyo. Gerentes, especialmente.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.