¿Cuál es el nombre de antipattern frente a "reinventar la rueda"? [cerrado]

101

El antipattern " Reinvent the wheel " es bastante común; en lugar de usar una solución lista para escribir, escribe el tuyo desde cero. La base del código crece innecesariamente, las interfaces ligeramente diferentes que hacen lo mismo pero ligeramente abundan de manera 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 es dos líneas de código, importe un marco / API / biblioteca, cree una instancia, configure, convierta el contexto a un tipo de datos como sea aceptable por el marco, y luego llame 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 necesita mantener la biblioteca actualizada, administrar las dependencias de compilación, mantener las licencias sincronizadas y su código de creación de instancias 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 que empuja su tecnología favorita 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 uso más amplio 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".

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

(No estoy intentando iniciar una discusión cuando está bien o mal, o si es una antipattern real o algo basado en la opinión , esta es una simple pregunta de nomenclatura directa y objetiva. )

Editar: el "duplicado" sugerido se refiere a un código propio de sobreingeniería para hacerlo "listo para todo", completamente separado de los sistemas externos. Esto puede derivarse en ciertos casos, pero generalmente se origina en la "aversión a reinventar la rueda": la reutilización del código a toda costa; Si existe una solución "preparada" para nuestro problema, la la utilizaremos, sin importar qué tan mal encaje y a qué costo. Favorece de forma dogmática 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.

    
pregunta SF. 18.04.2017 - 16:51
fuente

11 respuestas

9

No. No hay un nombre anti-patrón de uso común que cubra lo que está describiendo.

    
respondido por el JacquesB 19.04.2017 - 12:29
fuente
50

Golden Hammer

El martillo de oro es una herramienta elegida solo porque es elegante. No es ni rentable ni eficiente en realizar la tarea prevista.

fuente: xkcd 801

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

    
respondido por el martin 19.04.2017 - 06:01
fuente
34

Robert Martin utiliza el término " Framework Bound " para referirse a La consecuencia negativa más obvia de este anti-patró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.

    
respondido por el Jules 18.04.2017 - 22:22
fuente
18

Esta página de wikipedia en " Invented Here " describe una situación ligeramente diferente pero muy similar resultados finales. Describe la aversión de un equipo hacia la creación de su propio código cuando se puede encontrar una funcionalidad equivalente por ahí.

Yo diría que el nombre es un poco engañoso. Hace sentido cuando se pone en contexto con su opuesto No se ha inventado aquí que IMHO es prácticamente un sinónimo de Reinventar la rueda.

    
respondido por el Newtopian 18.04.2017 - 22:38
fuente
13

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

    
respondido por el wberry 19.04.2017 - 01:02
fuente
9
  

No uses un cañón para matar a un mosquito

     

Confucius

AKA Overkill

    
respondido por el Woofas 19.04.2017 - 06:07
fuente
8

Bloat 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 en sí contribuyen a un menor rendimiento / menor eficiencia y un mayor consumo de recursos (disco, ancho de banda).

Si lo deseamos, podemos aclarar con un término como dependencias hinchadas .

    
respondido por el jpmc26 19.04.2017 - 00:43
fuente
5

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

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

Por cierto, hay una distinción que debe dibujarse con infierno de dependencia . Si alguien ya ha envuelto 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 que la modificación futura del código encapsulado sea improbable necesario, luego un argumento restante en contra de su uso es el infierno de dependencia que podría estar causando.

    
respondido por el nigel222 19.04.2017 - 14:14
fuente
5

No creo que exista un análogo exacto, pero diría que el diseño excesivo o la ingeniería excesiva están más cerca

Al menos, diría que esto es lo que realmente está ocurriendo cuando me he encontrado con algo similar a lo que describiste.

El uso de una biblioteca en lugar de escribir su propio código para implementar la misma funcionalidad casi nunca es perjudicial.

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 en realidad es una biblioteca que intenta 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 le dé los dolores de cabeza que implica su pregunta.

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

Como funciones integradas que no son necesarias, prepararse para un futuro que quizás nunca llegue, etc.

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

    
respondido por el user82096 19.04.2017 - 13:25
fuente
4

Si no ha reinventado la rueda, lo más probable es que esté usando 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.

    
respondido por el Jon Raynor 18.04.2017 - 20:31
fuente
0

¿Seguridad del trabajo?
Mencionas todo el esfuerzo de mantener las cosas sincronizadas, etc. Algunas personas prefieren administrar el código de otras personas en lugar de escribir el suyo propio. Los gerentes, especialmente.

    
respondido por el user251748 19.04.2017 - 17:54
fuente

Lea otras preguntas en las etiquetas