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.