¿Reinventar la rueda es realmente tan malo?

Su conocimiento común en programación es que reinventar la rueda es malo o malo .

¿Pero por qué es eso?

No estoy sugiriendo que sea bueno. Creo que está mal. Sin embargo, una vez leí un artículo que decía que si alguien está haciendo algo mal (sabiamente en programación) explícales por qué está mal, si no puedes, entonces quizás deberías preguntarte si realmente está mal.

Eso me lleva a esta pregunta:

Si veo que alguien está reinventando claramente la rueda al construir su propio método de algo que ya está integrado en el lenguaje / marco. Primero, por el bien de los argumentos, supongamos que su método es tan eficiente como el método incorporado. También el desarrollador, consciente del método incorporado, prefiere su propio método.

¿Por qué debería usar el construido en uno sobre el suyo?

Como una vez publiqué en StackOverflow, reinventar la rueda es a menudo una muy buena opción , contrario a la creencia popular. La principal ventaja es que tiene control total sobre el software, que a menudo es esencial. Para una discusión completa, vea mi publicación original .

Depende ..

Como con todo, se trata del contexto:

Es bueno cuando:

• El marco o la biblioteca es demasiado pesado y solo necesita una funcionalidad limitada. Presentar su propia versión extremadamente liviana que satisfaga sus requisitos es un mejor enfoque.
• Cuando quiere comprender y aprender algo complejo, tiene sentido rodar el suyo.
• Tiene algo diferente que ofrecer, algo que las implementaciones de otros no tienen. Puede ser un nuevo giro, una nueva característica, etc.

Es malo cuando:

• La funcionalidad ya existe y se sabe que es estable y bien conocida (popular).
• Su versión no agrega nada nuevo.
• Su versión presenta errores o restricciones (por ejemplo, su versión no es segura para subprocesos).
• Su versión tiene características faltantes.
• Su versión tiene peor documentación.
• Su versión carece de pruebas unitarias en comparación con lo que está reemplazando.

Creo que el caso de un desarrollador que reinventa la rueda a sabiendas "porque prefiere su propio método" es bastante raro. Principalmente se hace por ignorancia y, a veces, por terquedad.

¿Es todo tan malo? Si. ¿Por qué? Debido a que la rueda existente probablemente se ha diseñado con el tiempo y ya se ha probado en muchas circunstancias y con muchos tipos diferentes de datos. El desarrollador (s) de la rueda existente ya ha encontrado los casos extremos y las dificultades que el reinventor ni siquiera puede imaginar todavía.

Las ruedas cuadradas deben reinventarse. Los esfuerzos que apestan tienen que ser duplicados. Tal vez hay una falta de documentación para el método, y el otro programador siente que es más fácil escribir el suyo en lugar de tratar de resolverlo. Quizás la forma en que se llama al método es incómoda y no se ajusta al lenguaje del lenguaje de programación.

Solo pregúntale cuál es la deficiencia.

En general, evito reinventar la rueda si la funcionalidad que deseo, o algo parecido, existe en la biblioteca estándar del lenguaje que uso.

Sin embargo, si tengo que incorporar bibliotecas de terceros, es una decisión de juicio dependiendo de cuán ampliamente utilizada y estimada sea la biblioteca. Quiero decir, ¿estamos hablando de Boost o Bob's Kick-ass String-Parsing Tools 1.0?

Incluso si la biblioteca es generalmente conocida y altamente estimada en toda la industria, sigue siendo una dependencia de terceros . Los programadores generalmente ponen un énfasis significativo en las virtudes de la reutilización del código, mientras que a menudo pasan por alto el peligro de las dependencias. Es probable que un proyecto con demasiadas dependencias de terceros se desmorone a largo plazo, ya que lentamente se convierte en una pesadilla de mantenimiento.

Por lo tanto, aprovechar el código existente es bueno , pero las dependencias son malas . Desafortunadamente, estas dos declaraciones están en desacuerdo entre sí, por lo que el truco está en encontrar el equilibrio correcto. Es por eso que necesita identificar dependencias aceptables . Como dije, cualquier cosa en la Biblioteca Estándar del lenguaje es probablemente una dependencia aceptable. Pasando de allí, las bibliotecas, que son muy apreciados en toda la industria también son generalmente aceptables (como Boost para C ++, o jQuery JavaScript) - pero todavía son menos deseables que la biblioteca estándar, ya que no tienden a ser menos estables que las bibliotecas normalizadas .

En cuanto a las bibliotecas que son relativamente desconocidas (por ejemplo, la última carga en SourceForge), estas son dependencias extremadamente riesgosas, y generalmente recomendaría evitarlas en el código de producción, a menos que esté lo suficientemente familiarizado con el código fuente para mantenerlas usted mismo.

Entonces, en realidad todo es un acto de equilibrio. Pero el punto es que solo diciendo a ciegas "¡Reutilización del código es buena! ¡Reinventar la rueda es mala!" Es una actitud peligrosa. Los beneficios de aprovechar el código de terceros deben sopesarse frente a las desventajas de introducir dependencias.

Si la gente no reinventara las ruedas, el mundo se llenaría de estos ...

Aquí hay un diálogo desde mi lugar de trabajo:

- I would like to add some colors to the output of this program.
- Oh, there is this library called Colorama ..

Hay dos opciones: reinventar la rueda O usar Colorama. Esto es lo que resultaría en cada opción:

Usando Colorama

• Quizás un poco más rápido para correr
• Agregar una dependencia de terceros para algo trivial
• Sigues siendo tan estúpido como antes de usar Colorama

Reinventando la rueda

• Entiende cómo algunos programas pueden mostrar color
• Aprende que se pueden usar caracteres especiales para colorear en cualquier terminal
• Puede colorear en cualquier lenguaje de programación que pueda usar en el futuro
• Es menos probable que su proyecto se rompa

Como puede ver, todo depende del contexto. Reinventar la rueda es algo que hago muy a menudo porque quiero poder y pensar por mí mismo y no confiar en que otras personas piensen por mí. Sin embargo, si está ejecutando una fecha límite o lo que intenta implementar es enorme y ya existe, entonces es mejor que use lo que está allí.

Una razón útil para reinventar la rueda es para fines de aprendizaje, pero recomendaría hacerlo en su propio tiempo. A medida que hay más soluciones preparadas disponibles y se proporcionan más niveles de abstracción, nos volvemos mucho más productivos. Podemos centrarnos en el problema empresarial en lugar de las cosas genéricas que se han modificado una y otra vez. PERO, por esa razón, puede mejorar sus habilidades y aprender mucho al tratar de implementar una solución por su cuenta. Simplemente no necesariamente para uso en producción.

Otra cosa: si una preocupación es la dependencia en una biblioteca de terceros de una empresa que puede desaparecer, asegúrese de que haya una opción para obtener el código fuente, o al menos un par de otras opciones para recurrir.

Por cierto, si elige implementar la suya, evite hacerlo para la criptografía u otra funcionalidad relacionada con la seguridad. Las herramientas establecidas (y completamente probadas) están disponibles para eso, y hoy en día, es muy arriesgado rodar las suyas. Eso nunca vale la pena, y da miedo que todavía escuche sobre los equipos que hacen esto.

Hay dos tipos de eficiencia: procesamiento / velocidad (es decir, qué tan rápido se ejecuta) con la que puede coincidir y velocidad de desarrollo que casi seguro que no. Esa es la primera razón: para cualquier problema de complejidad razonable en el que las soluciones existentes estén disponibles, seguramente será más rápido investigar e implementar una biblioteca existente que codificar la suya .

La segunda razón es que la biblioteca existente (suponiendo que esté madura) se prueba y se prueba que funciona , probablemente en una gama mucho más amplia de escenarios que un desarrollador y un equipo de prueba podrá llevar a cabo una rutina recién escrita y esto se logra esfuerzo cero

En tercer lugar, es mucho más fácil de soportar. No solo alguien más lo admite y lo mejora (quien escribió la biblioteca / componente), sino que es mucho más probable que otros desarrolladores estén familiarizados con él y puedan comprender y mantener el código en el futuro , todo lo cual minimiza la continuidad costos.

Y todo eso supone una equivalencia funcional, que normalmente no es el caso. Con frecuencia, las bibliotecas ofrecerán funcionalidades que le resultarán útiles, pero que nunca podrían justificar la creación, todo lo cual de repente está disponible de forma gratuita.

Hay razones para hacer las suyas propias, en gran medida donde desea hacer algo que la función incorporada no puede hacer y donde hay una ventaja genuina que se puede obtener al hacerlo, o donde las opciones disponibles no están maduras, pero son menos comunes de lo que muchos desarrolladores te hacen creer

Además, ¿por qué querrías pasar tu tiempo resolviendo problemas que ya se han resuelto? Sí, es una excelente manera de aprender, pero no debería hacerlo a costa de la solución adecuada para el código de producción, que es de lo que estoy suponiendo que estamos hablando.

Por supuesto, reinventar la rueda por capricho, por ignorancia y arrogancia puede ser algo malo, pero en mi humilde opinión, el péndulo ha oscilado demasiado. Hay una enorme ventaja de tener una rueda que hace exactamente lo que quiere y nada más .

A menudo, cuando miro una rueda existente, hace mucho más de lo que necesito, sufre el efecto de plataforma interna y , por lo tanto , es innecesariamente compleja, o le falta alguna característica clave que necesito y que sería difícil de implementar encima de lo que ya está allí.

Además, el uso de ruedas existentes a menudo agrega restricciones a mi proyecto que no quiero. Por ejemplo:

• La rueda existente requiere un lenguaje y / o estilo de programación diferente al que preferiría usar.
• La rueda existente solo funciona con la versión heredada de un lenguaje (por ejemplo, Python 2 en lugar de Python 3).
• Donde hay compensaciones entre eficiencia, flexibilidad y simplicidad, la rueda existente toma decisiones que son subóptimas para mi caso de uso. (Se sabe que reinventé incluso la funcionalidad de las bibliotecas que escribí originalmente en estos casos. Por lo general, es porque escribí la versión de la biblioteca de la función para que sea genérica y razonablemente eficiente, cuando actualmente necesito algo que sea muy rápido en mi caso.)
• La rueda existente tiene toneladas de migajas heredadas que son totalmente inútiles en el caso de un código nuevo pero que, sin embargo, dificultan la vida (por ejemplo, una biblioteca Java que uso que me obliga a usar sus clases de contenedores de porquería porque fue escrita antes de los genéricos, etc.) .
• La forma en que la rueda existente modela el problema es completamente diferente de lo que es conveniente para mi caso de uso. (Por ejemplo, quizás sea conveniente para mí tener un gráfico dirigido representado por objetos de nodo y referencias, pero la rueda existente usa una matriz de adyacencia o viceversa. Quizás sea conveniente para mí colocar mis datos en el orden principal de la columna, pero el la rueda existente insiste en la fila mayor o viceversa)
• La biblioteca agrega una dependencia masiva y frágil que sería una gran molestia para poner en funcionamiento en todos los lugares donde quiero implementar mi código, cuando todo lo que necesito es un pequeño subconjunto de sus características. Por otro lado, en este caso, a veces solo extraigo la función que quiero en una biblioteca nueva y más pequeña o simplemente copio / pego si la biblioteca es de código abierto y la base de código lo hace lo suficientemente simple. (Incluso he hecho esto con bibliotecas relativamente grandes que he escrito yo mismo, no solo de otras personas).
• La rueda existente intenta cumplir pedantemente con algún estándar que es inconveniente e irrelevante para mi caso de uso.

A menudo uso el mío porque lo construí antes de descubrir el preexistente, y soy demasiado vago como para buscar y reemplazar cada instancia. Además, entiendo completamente mi propio método, aunque es posible que no entienda uno anterior. Y finalmente, debido a que no entiendo completamente el preexistente, no puedo verificar que haga absolutamente todo lo que hace mi actual.

Hay mucho que codificar, y no tengo mucho tiempo para volver y volver a codificar algo a menos que afecte la producción.

De hecho, una aplicación web asp que todavía se usa hoy en día tiene un gráfico completamente funcional que muestra datos en un formato tabular y permite la clasificación / edición, sin embargo, no es una cuadrícula de datos. Fue construido hace unos años cuando estaba aprendiendo asp.net por primera vez y no conocía las cuadrículas de datos. Tengo un poco de miedo al código ya que no tengo idea de lo que estaba haciendo en ese momento, pero funciona, es preciso, es fácil de modificar, no se bloquea y los usuarios lo adoran

Reinventar la rueda es una excelente manera de aprender cómo funciona, pero no es una buena manera de construir un automóvil.

Actualmente trabajo para un montón de tacaños.

Cuando la decisión se toma entre "construir o comprar", en lugar de tomar una decisión racional basada en la economía, los gerentes optan por "construir". Esto significa que en lugar de pagar unos pocos miles de dólares por un componente o herramienta, pasamos meses hombre construyendo el nuestro. La compra de una rueda de otra compañía cuesta dinero que sale del presupuesto, lo que cuenta contra las bonificaciones de fin de año de mala gestión. El tiempo de los programadores es gratuito y, por lo tanto, no cuenta para las bonificaciones de fin de año (con el beneficio adicional de desanimar a los programadores por no hacer todo "a tiempo"), por lo tanto, una rueda reinventada es una rueda libre .

En una empresa racional, el costo versus los beneficios de comprar ruedas hechas por otros versus reinventar las propias ruedas se basarían en los costos a corto y largo plazo, así como en los costos de oportunidad perdidos porque uno no puede hacer nuevos widgets mientras uno está reinventando ruedas. Cada día que pasas reinventando la rueda es otro día en el que no puedes escribir algo nuevo.

Presentación sobre construcción vs compra .
Artículo sobre construcción vs compra .

Si veo que alguien está reinventando claramente la rueda al construir su propio método de algo que ya está integrado en el lenguaje / marco. Primero, por el bien de los argumentos, supongamos que su método es tan eficiente como el método incorporado. También el desarrollador, consciente del método incorporado, prefiere su propio método.

¿Por qué debería usar el construido en uno sobre el suyo?

La versión incorporada habrá tenido mucha más gente golpeándola, encontrando y reparando más errores de los que puede tener su código homebrew.

Finalmente, cuando su desarrollador local se va, y alguien más tiene que mantener el código que escribió, se reestructurará por completo y se reemplazará con lo que está en el marco. Sé que esto sucederá porque mi empleador actual tiene un código que se ha migrado a versiones más recientes de VB a lo largo de los años (el producto más antiguo ha estado en el mercado durante aproximadamente 20 años) y esto es lo que sucedió. El desarrollador con el empleo más largo en mi oficina ha estado aquí 17 años.

Lo importante de reinventar la rueda es que a veces no hay una rueda estándar estándar que haga lo que necesita. Hay muchas ruedas buenas por ahí, en muchos tamaños, colores, materiales y modos de construcción. Pero algunos días solo tienes que tener una rueda realmente liviana que sea de aluminio anodizado verde, y nadie la fabrica. En ese caso, TIENES que hacer el tuyo.

Ahora, eso no quiere decir que debe hacer sus propias ruedas para cada proyecto: la mayoría de las cosas pueden usar piezas estándar y ser mejores para ello. Pero de vez en cuando, descubres que las piezas estándar simplemente no funcionan, así que haces las tuyas.

Lo más importante es saber CUANDO hacer el tuyo. Debe tener una buena idea de lo que pueden hacer las piezas estándar y de lo que no pueden hacer, antes de comenzar a diseñar las suyas.

Si reinventar o no la rueda es una cuestión de costo / beneficio. Los costos son bastante obvios ...

• Se necesita mucho tiempo para reinventar.
• Lleva aún más tiempo documentar lo que has inventado.
• No puedes contratar personas que ya entiendan lo que has inventado.
• Es muy fácil reinventar algo mal, causando costos continuos por los problemas causados ​​por el mal diseño.
• Nuevo código significa nuevos errores. El código antiguo generalmente ya ha eliminado la mayoría de los errores, y puede tener soluciones sutiles a problemas que no conoce y, por lo tanto, no puede evitar en el nuevo diseño.

Lo último es importante: hay una publicación de blog en algún lugar que advierte sobre la tendencia a "tirar el código viejo y comenzar desde cero" sobre la base de que gran parte de la vieja información que no entiendes es en realidad correcciones de errores esenciales. Hay una historia de advertencia sobre Netscape, IIRC.

Las ventajas pueden ser ...

• La capacidad de agregar funciones que las bibliotecas existentes no tienen. Por ejemplo, tengo contenedores que "mantienen" sus instancias de iterador / cursor. Las inserciones y eliminaciones no invalidan los iteradores. Un iterador que apunta a un vector continuará apuntando al mismo elemento (no al mismo índice) independientemente de las inserciones y eliminaciones anteriores en el vector. Simplemente no puede hacer eso con contenedores estándar de C ++.
• Un diseño más especializado dirigido a sus requisitos particulares y respetando sus prioridades (pero tenga cuidado con la tendencia hacia el efecto de plataforma interna).
• Control completo: algunos terceros no pueden decidir rediseñar la API de una manera que significa que tiene que reescribir la mitad de su aplicación.
• Comprensión completa: lo ha diseñado de esa manera, por lo que es de esperar que comprenda completamente cómo y por qué lo hizo.
• EDITAR Puede aprender las lecciones de otras bibliotecas sin quedar atrapado en las mismas trampas al ser selectivo sobre cómo las imita.

Una cosa: usar una biblioteca de terceros puede contar como reinventar la rueda. Si ya tiene su propia biblioteca antigua, bien utilizada y probada, piense detenidamente antes de descartarla para utilizar una biblioteca de terceros. Puede ser una buena idea a largo plazo, pero puede haber una gran cantidad de trabajo y muchas sorpresas desagradables (de sutiles diferencias semánticas entre las bibliotecas) antes de llegar allí. Por ejemplo, considere el efecto de cambiarme de mis propios contenedores a los de la biblioteca estándar. Una traducción ingenua del código de llamada no permitiría el hecho de que los contenedores estándar de la biblioteca no mantengan sus iteradores. Los casos en los que guardo un iterador para más tarde como un "marcador" no se pudieron implementar utilizando una traducción simple en absoluto: "

Si hay un componente funcional que hace lo que necesita , ¿por qué dedicar tiempo a escribir y depurar su propia versión? Del mismo modo, si ya ha escrito código para cumplir una función similar anteriormente, ¿por qué volver a escribirlo?

Joel escribió un artículo sobre No inventado aquí que habla mucho sobre cuándo volver a escribir código y software no es y no es útil.

Reinventar la rueda puede ser una excelente manera de aprender cómo funciona algo, y recomiendo reinventar solo para ese propósito en su propio tiempo, pero al escribir una aplicación, ¿por qué reinventar si hay soluciones bien establecidas que ya hacen lo mismo?

Por ejemplo, nunca escribiría código JavaScript desde cero; en cambio, comenzaría con jQuery y construiría mis aplicaciones sobre ese marco.

Mi regla de oro personal:

Reinventar la rueda es bueno cuando solo estás aprendiendo. Si tiene una fecha límite, puede usar las ruedas existentes.

Ser "malo" o incluso "malo" son palabras bastante fuertes.

Como siempre, hay razones para elegir una implementación personal en lugar de una integrada. En los viejos tiempos, un programa C podía encontrar errores en la biblioteca de tiempo de ejecución y, por lo tanto, simplemente tenía que proporcionar su propia implementación.

Esto no se aplica a los programas Java, ya que la JVM está muy estrictamente definida, pero algunos algoritmos aún son muy difíciles de entender. Por ejemplo, Joshua Bloch describe cómo el algoritmo de búsqueda binaria engañosamente simple en la biblioteca de tiempo de ejecución de Java contenía un error, que tardó nueve años en aparecer:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Fue encontrado, reparado y distribuido en futuras distribuciones de Java.

Si utiliza la búsqueda binaria incorporada, acaba de ahorrar tiempo y dinero al hacer que Sun haga el trabajo duro para encontrar, arreglar y distribuir esta corrección de errores. Puede aprovechar su trabajo simplemente diciendo "necesita al menos la actualización 10 de Java 6".

Si usa su propia implementación, que probablemente también contenga este error, primero necesita el error para manifestarse. Dado que este en particular solo se muestra en GRANDES conjuntos de datos, es probable que suceda en la producción en algún lugar, lo que significa que al menos uno de sus clientes se verá afectado y probablemente perderá dinero real mientras encuentra, repara y distribuye la corrección de errores.

Por lo tanto, es perfectamente válido preferir su propia implementación, pero la razón es que sea realmente buena, ya que seguramente será más costosa que aprovechar el trabajo de los demás.

Hace poco escribí mis pensamientos sobre este tema. Para resumir:

1. Casi siempre es malo construir uno propio, especialmente cierto si se trata de una función integrada en el lenguaje. Pero si está evaluando un marco inmaduro / cuestionablemente mantenido / mal documentado que encontró en Internet en contra de la posibilidad de escribir el suyo, podría ser obvio.

2. Creo que reinventar la rueda es una analogía bastante horrible para un antipatrón de software. Implica que la solución original nunca puede mejorarse. Eso no tiene sentido. La llamada rueda puede quedar obsoleta de la noche a la mañana, o sus propietarios podrían dejar de mantenerla. La rueda tiene un valor diferente en cada sistema donde se usa. Por lo tanto, a menudo es completamente posible inventar una mejor rueda.

3. Una de las principales ventajas de crear su propio marco es que no tendrá que responsabilizarse por los errores de otra persona. (Esta es la filosofía de Amazon ). Piénselo de esta manera: ¿cuál de estos es mejor decirle a un cliente? -

   "Nuestro sitio web se rompió. Fue culpa de otra persona, y hemos registrado un error con su creador. No hay nada que podamos hacer al respecto, excepto esperar. Lo mantendremos informado".

   "Nuestro sitio web se rompió y pudimos solucionarlo de inmediato".

Tal vez sea igual de eficiente, pero ¿es tan robusto? Creo que la razón más convincente para usar una biblioteca sobre la suya propia es que el marco tiene tantas personas que la usan que pueden encontrar y corregir errores rápidamente. La biblioteca desarrollada internamente, aunque puede proporcionar la misma funcionalidad (o más), no puede competir con una biblioteca con millones de usuarios para proporcionar pruebas en casi todos los casos de uso. Simplemente no se puede superar ese tipo de pruebas en la empresa.

Bueno, su propio método es tan eficiente como el marco sería bastante raro porque la mayoría de los marcos aún tienen errores y ningún marco puede brindarle una solución lista para usar. La mayoría de los programadores que no pueden pensar nunca intentarán escribir nada a nivel de marco; solo buscarán en Google una solución preparada. Cualquier programador inteligente primero verá si hay un marco gratuito que tenga la funcionalidad que necesita, y luego escribirá la solución él mismo si no la hay. A veces es demasiado difícil explicar la situación actual del proyecto y el desarrollador es el mejor juez.

Reinventar la rueda no es malo, es una declaración hecha por gente perezosa para evitar trabajar duro. Incluso los escritores de marcos reinventan; Todo el framework .Net se reinventó para hacer lo que COM estaba ofreciendo.

Por ofensivo que pueda ser para algunos, siempre he encontrado que este término no es inteligente cuando lo usa cualquier forma de ingeniero o en referencia a un tema de creación o diseño de cosas. De hecho, no puedo evitar verlo como falso cuando considero las presiones para innovar en el mundo acelerado de hoy. Repetirse (o ignorar soluciones adecuadas y preexistentes) nunca es prudente, pero realmente, hay una razón por la cual no todos seguimos mirando pantallas negras llenas de letras verdes.

Entiendo "Si no está roto, no lo arregles", aunque supongo que tal frase puede sonar ignorante para algunos. Sin embargo, con el esfuerzo actual de reinventar la rueda para las necesidades de viajes espaciales, carreras, envíos, etc., "no reinventar la rueda" también es bastante ignorante, y no es tan inteligente como parece.

Mi experiencia consiste en liderar muchos proyectos y tuve que trabajar con muchos pasantes y otras formas de desarrolladores ecológicos, y tuve que manejar muchas preguntas ingenuas que algunos llamarían 'estúpidas', y también tuve que desviar a la gente de perseguir a los conejos. totalidades fuera del alcance de sus tareas. Sin embargo, nunca desalentaría la innovación o la creatividad, y he visto grandes cosas venir de 'reinventar la rueda'.

Mi respuesta real a la pregunta: solo hay dos situaciones que hacen que reinventar la rueda sea algo malo:

1. Si realmente no es necesario
2. Si es el otro chico que lo hace cuando podrías

Editar: puedo ver por los votos negativos que debo haber ofendido a algunos. Lo único que me gustaría agregar es que esta frase siempre ha sido una de mis principales preocupaciones. Entiendo que mis dos centavos pueden sonar bastante troll, pero no tengo intenciones de troll, provocar incendios u ofender.

Los argumentos sobre "reinventar una rueda" a menudo se usan en el contexto equivocado de elegir usar una biblioteca, pero no es algo similar.

Digamos que estoy evaluando una biblioteca 'formularios plus', que recientemente se hizo popular recientemente y ayuda a manejar los formularios. Tiene una bonita página de aterrizaje, gráficos modernos y geniales (oops, me refiero a la comunidad) a su alrededor que jura cómo hace que las formas sean geniales nuevamente. Pero "formas más" es una abstracción sobre "formas". "formas" era posible pero engorroso de manejar, por lo que la abstracción que lo hace más fácil se está volviendo popular.

Nuevas abstracciones están sucediendo todo el tiempo. Es difícil compararlos con las ruedas. Es más como un nuevo dispositivo de control y un nuevo manual para cualquier dispositivo que ya sea muy complicado que necesite ejecutar.

La valoración de este nuevo dispositivo "formularios plus" se verá diferente dependiendo de la experiencia personal. Si nunca construí formularios antes, entonces "formularios plus" será muy convincente porque es más fácil comenzar. La desventaja es que si "formas más" resulta ser una abstracción permeable, todavía tendré que aprender "formas" de todos modos. Si estaba creando formularios sin "formularios plus", entonces tendré que tener en cuenta el tiempo que necesito para aprender una nueva herramienta. Lo positivo es que ya conozco "formas", así que no tengo miedo de las abstracciones. Los beneficios a corto plazo a menudo serán mayores para los nuevos principiantes porque probablemente no habría una nueva biblioteca si no mejorara algo. Los beneficios a largo plazo variarán ampliamente en la calidad de la abstracción, la tasa de adopción,

Después de evaluar cuidadosamente los beneficios y aspectos negativos del uso de una nueva abstracción "formas más" frente al uso de "formas" básicas, tomo una decisión. La decisión se basa en gran medida en mis experiencias personales y diferentes personas tomarán decisiones diferentes. Podría haber elegido usar "formas" al descubierto. Tal vez más adelante en el tiempo, las formas plus habían ganado más movimiento y se convirtieron en un estándar de facto. Y tal vez mi propia implementación a lo largo del tiempo se volvió complicada y comenzó a cubrir mucho de lo que están haciendo las formas más ahora. La gente que viene en este momento se sentirá atraída a criticar que estoy interesado en reinventar la rueda y que debería haber usado la biblioteca existente. Pero también es posible que en el momento en que tuve que tomar una decisión sobre "formularios plus", también había muchas otras alternativas a "formularios plus",

Al final, elegir las herramientas adecuadas es una decisión complicada de tomar y la "reinvención de la rueda" no es una perspectiva muy útil.

Escribí un pequeño artículo sobre esto: http://samueldelesque.tumblr.com/post/77811984752/what-re-inventing-the-wheel-can-teach-you

En mi experiencia, reinventar ha sido realmente genial, aunque muy largo y tedioso. Diría que si no conoce exactamente los modelos de programación que va a utilizar, escríbalos usted mismo (si tiene tiempo y energía). Esto le enseñará qué significan exactamente esos modelos de programación y, en última instancia, se convertirá en un mejor programador. Por supuesto, si está trabajando para un cliente y solo necesita obtener algo rápidamente, es probable que solo desee investigar un poco y encontrar el software adecuado para usted.