¿Es realmente tan malo reinventar la rueda?

Como una vez publiqué en StackOverflow, reinventar la rueda es a menudo una muy buena opción , contrariamente a la creencia popular. La principal ventaja es que tienes 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 de contexto:

Es bueno cuando:

• El marco o la biblioteca es demasiado pesado y solo se requiere una funcionalidad limitada. Hacer rodar su propia versión extremadamente liviana que satisfaga sus necesidades es un mejor enfoque.
• Cuando quieres entender y aprender algo complejo, hacer rodar lo tuyo tiene sentido.
• Usted 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 conocida (popular).
• Tu versión no agrega nada nuevo.
• Su versión introduce errores o restricciones (por ejemplo, su versión no es segura para subprocesos).
• A tu versión le faltan funciones.
• Su versión tiene peor documentación.
• A su versión le faltan pruebas de unidad 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 tan malo? Sí. ¿Por qué? Debido a que la rueda existente probablemente ha sido diseñada a lo largo del tiempo y ya ha sido probada en muchas circunstancias y en contra de muchos tipos diferentes de datos. El (los) desarrollador (es) de la rueda existente ya se han encontrado con los casos y las dificultades que el reinventor no puede imaginar todavía.

Las ruedas cuadradas tienen que ser reinventadas. Los esfuerzos que apestan tienen que ser duplicados. Quizás haya una falta de documentación para el método, y el otro programador siente que es más fácil simplemente escribir el suyo en lugar de tratar de averiguarlo. Tal vez la forma en que se llama al método es torpe 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 idioma 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 muy apreciada 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. Un proyecto con demasiadas dependencias de terceros es probable que 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 afirmaciones están en desacuerdo entre sí, por lo que el truco es tratar de encontrar el equilibrio correcto. Es por eso que necesita identificar las dependencias aceptables . Como dije, cualquier cosa en la biblioteca estándar del idioma es probablemente una dependencia aceptable. A partir de ahí, las bibliotecas que gozan de gran prestigio en toda la industria también son generalmente aceptables (como Boost para C ++ o jQuery para Javascript), pero siguen siendo menos deseables que la Biblioteca estándar porque do tiende a ser menos estable que las bibliotecas estandarizadas.

En cuanto a las bibliotecas que son relativamente desconocidas (p. ej., 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.

Así que realmente es todo un acto de equilibrio. Pero el punto es que simplemente diciendo ciegamente "¡Reutilización de código buena! ¡Reinventar rueda mal!" Es una actitud peligrosa. Los beneficios de aprovechar el código de terceros deben compararse con las desventajas de introducir dependencias.

Una razón útil para reinventar la rueda es para propósitos de aprendizaje, pero recomendaría hacerlo en su propio tiempo. A medida que se dispone de más soluciones precocinadas y se proporcionan más niveles de abstracción, nos volvemos mucho más productivos. Podemos centrarnos en el problema del negocio en lugar de en 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 volver a implementar una solución por su cuenta. Simplemente no necesariamente para uso de producción.

Otra cosa: si una inquietud es la dependencia de 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 volver a usar .

Por cierto, si elige implementar el suyo propio, evite hacer esto para la criptografía u otra funcionalidad relacionada con la seguridad. Las herramientas establecidas (y totalmente probadas) están disponibles para eso, y en esta época es demasiado arriesgado rodar las tuyas. Eso nunca vale la pena, y da miedo que todavía escuche que los equipos hacen esto.

Si la gente no reinventara las ruedas, el mundo se llenaría con 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. Aquí está lo que cada opción resultaría en:

Usando Colorama

• Tal vez 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

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

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

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

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

En tercer lugar, es mucho más fácil de soportar. alguien más lo apoya y mejora (quien haya escrito la biblioteca / componente), pero es mucho más probable que otros desarrolladores estén familiarizados con él y puedan entender y mantener el código. en adelante , todo lo cual minimiza los costos en curso.

Y todo eso supone una equivalencia funcional, que normalmente no es el caso. Con frecuencia, las bibliotecas ofrecerán una funcionalidad que usted encontrará útil pero que nunca podría justificar la creación, y que de repente está disponible de forma gratuita.

Hay razones para rodar las suyas: en gran parte, cuando quiere hacer algo que la función incorporada no puede hacer y donde hay una ventaja genuina que se obtiene 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ía dedicar su tiempo a resolver problemas que ya se han resuelto? Sí, es una excelente manera de aprender, pero no debería hacerlo a costa de la solución correcta para el código de producción, que es lo que supongo 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 se ha movido demasiado lejos. Hay una gran ventaja de tener una rueda que hace exactamente lo que quiere y nada más .

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

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 yo preferiría usar.
• La rueda existente solo funciona con la versión heredada de un idioma (por ejemplo, Python 2 en lugar de Python 3).
• Donde hay compensaciones entre eficiencia, flexibilidad y simplicidad, la rueda existente hace elecciones que no son óptimas para mi caso de uso. (Se sabe que reinventé incluso la funcionalidad de las bibliotecas que originalmente escribí en estos casos. Por lo general, es porque escribí que la versión de la biblioteca de la función es genérica y razonablemente eficiente, cuando actualmente necesito algo que es muy rápido en mi versión específica. caso.)
• La rueda existente tiene toneladas de cruceros heredados que son totalmente inútiles en el caso del nuevo código, pero aún así hace la vida difícil (por ejemplo, una biblioteca de Java que uso me obliga a usar sus clases de contenedores de mierda 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, tal vez 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. Tal vez sea conveniente para mí colocar mis datos en el orden de la columna principal, pero la rueda existente insiste en la fila mayor o viceversa.)
• La biblioteca agrega una dependencia masiva y quebradiza que sería una molestia importante para instalar y ejecutar en cualquier lugar donde quiera 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 simplemente 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 hace que hacerlo sea lo suficientemente simple. (Incluso he hecho esto con bibliotecas relativamente grandes que he escrito yo, no solo de otras personas).
• La rueda existente intenta cumplir de manera pedante 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 que descubriera el preexistente, y soy demasiado vago para buscar y reemplazar cada instancia. Además, entiendo completamente mi propio método, mientras que podría no entender uno preexistente. Y, por último, porque no entiendo completamente el preexistente, no puedo verificar que haga absolutamente todo lo que hace el actual.

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

De hecho, una aplicación web de asp que todavía se usa hoy en día tiene un gráfico totalmente funcional que muestra los datos en un formato tabular y permite la clasificación / edición, sin embargo, no es un dato. Fue construido hace unos años, cuando estaba aprendiendo por primera vez en asp.net y no sabía nada de datagrids. Estoy un poco asustado con el código ya que no tengo ni idea de lo que estaba haciendo en ese entonces, pero funciona, es preciso, es fácil de modificar, no falla y a los usuarios les encanta

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

Actualmente trabajo para un grupo de cheapskates.

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 decidieron "construir". Esto significa que, en lugar de pagar unos pocos miles de dólares por un componente o herramienta, gastamos meses-hombre para construir el nuestro. Comprar una rueda de otra compañía cuesta dinero que sale del presupuesto, lo que cuenta con los bonos de fin de año mal administrados. El tiempo de los programadores es gratuito y, por lo tanto, no cuenta contra las bonificaciones de fin de año (con la ventaja adicional de que los programadores no hagan todo "a tiempo"), por lo que una rueda reinventada es una rueda libre .

En una empresa racional, el costo frente a los beneficios de comprar ruedas fabricados por otros frente a reinventar las propias ruedas se basaría en los costos a corto y largo plazo, así como en los costos de oportunidad perdidos porque no se pueden crear nuevos widgets. Mientras se está reinventando ruedas. Cada día que pasa reinventando la rueda es otro día que no puede escribir algo nuevo.

Presentación sobre la acumulación vs comprar
Artículo sobre compilación contra compra .

  

Si veo que alguien está reinventando claramente la rueda, está creando su propio método de algo que ya está incorporado en el lenguaje / marco. En primer lugar, por razones, 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 que la atacará, por lo que encontrará y solucionará más errores de los que pueda tener su código Homebrew.

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

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

Ahora, eso no quiere decir que deba hacer sus propias ruedas para cada proyecto; la mayoría de las cosas pueden usar partes estándar y ser mejores para ellas. Pero de vez en cuando, encuentras que las partes estándar simplemente no funcionan, así que haces las tuyas propias.

Lo más importante es saber cuándo hacer el tuyo. Debes tener una buena idea de lo que pueden hacer las partes estándar y lo que no pueden, antes de que comiences a diseñar la tuya.

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

• Se necesita mucho tiempo para reinventar.
• Se necesita más tiempo para documentar lo que has inventado.
• No puedes contratar a personas que ya entienden lo que has inventado.
• Es muy fácil reinventar algo mal, lo que causa costos continuos por los problemas causados por el mal diseño.
• Nuevo código significa nuevos errores. El código antiguo por lo general 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 solucionar el nuevo diseño.

Lo último es importante: hay una publicación de blog en algún lugar que advierte sobre la tendencia a "deshacerse del código antiguo y comenzar de cero" sobre la base de que gran parte del antiguo texto que no entiendes es realmente una corrección de errores. Hay una historia de advertencia sobre Netscape, IIRC.

Las ventajas pueden ser ...

• La capacidad de agregar características 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 los contenedores estándar de C ++.
• Un diseño más especializado que se adapta a sus requisitos particulares y respeta sus prioridades (pero tenga cuidado con la tendencia hacia el efecto de plataforma interna).
• Control total: algunos terceros no pueden decidir rediseñar la API de manera que tengas que volver a escribir la mitad de tu aplicación.
• Comprensión completa: lo has diseñado de esa manera, así que espero que entiendas completamente cómo y por qué lo hiciste.
• EDITAR Puedes aprender las lecciones de otras bibliotecas sin ser atrapado en las mismas trampas si eres selectivo sobre cómo las imitas.

Una cosa: usar una biblioteca de terceros puede contar como reinventar la rueda. Si ya tiene su propia biblioteca antigua, bien usada y bien probada, piense detenidamente antes de descartarla para usar una biblioteca de terceros. Puede que sea una buena idea a largo plazo, pero puede haber una gran cantidad de trabajo y muchas sorpresas desagradables (por las sutiles diferencias semánticas entre las bibliotecas) antes de llegar allí. Por ejemplo, considere el efecto de cambiar de mis contenedores a los de biblioteca estándar. Una traducción ingenua del código de llamada no permitiría el hecho de que los contenedores de la biblioteca estándar no mantienen sus iteradores. Los casos en los que guardo un iterador para más adelante como un "marcador" no podrían implementarse con una traducción simple, necesitaría algún medio alternativo no trivial para indicar las posiciones de los marcadores.

Si hay un componente en funcionamiento que hace lo que necesitas , ¿por qué dedicar tiempo a escribir y depurar tu 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 en Not-invented-here que dice mucho sobre cuándo reescribir 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 con 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 lugar de eso, comenzaría con jQuery y construía mis aplicaciones sobre ese marco.

Mi regla de oro personal:

Reinventar la rueda es bueno cuando estás aprendiendo. Si tiene una fecha límite, es posible que desee utilizar 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 incorporada. En los viejos tiempos, un programa de C podría encontrar errores en la biblioteca de tiempo de ejecución y, por lo tanto, simplemente tienen 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 corregir. Por ejemplo, Joshua Bloch describe cómo el algoritmo de búsqueda binaria simple y engañoso en la biblioteca de tiempo de ejecución de Java contenía un error, que tardó nueve años en aparecer:

enlace

Se encontró, reparó y distribuyó en futuras distribuciones de Java.

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

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 ocurra en la producción en algún lugar, lo que significa que al menos uno de sus clientes se verá afectado y es muy probable que pierda dinero real mientras encuentra, corrige y distribuye la corrección de errores.

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

Recientemente he blogging mis pensamientos sobre este tema. Para resumir:

1. Es casi siempre mal construir el tuyo, especialmente si es una función que está incorporada en el lenguaje. Pero si está evaluando un marco inmaduro / cuestionable mantenido / mal documentado que encontró en Internet contra la posibilidad de escribir el suyo propio, podría ser una obviedad.

2. Creo que reinventar la rueda es una analogía bastante terrible para un anti-patrón de software. Implica que la solución original nunca puede ser mejorada. Eso es una tontería. La llamada rueda puede volverse 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 posible inventar una mejor rueda.

3. Uno de los principales beneficios de crear su propio marco es que no tendrá que responsabilizarse por los errores de otra persona. (Esto es 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 arreglarlo de inmediato".

Tal vez sea igual de eficiente, pero es tan robusto? Creo que la razón más convincente para usar una biblioteca en lugar de rodar la tuya es que el marco tiene tanta gente que la usa que pueden encontrar y corregir errores rápidamente. Las bibliotecas desarrolladas internamente, si bien pueden proporcionar la misma funcionalidad (o más), no pueden competir con una biblioteca con millones de usuarios para realizar pruebas en casi todos los casos de uso. Simplemente no puedes superar ese tipo de pruebas internas.

Bueno, su propio método de ser tan eficiente como el marco sería bastante raro porque la mayoría de los marcos todavía tienen errores y ningún marco puede darte 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 ya hecha. Cualquier programador sabio primero verá si hay un marco de trabajo gratuito que tenga la funcionalidad que necesita, y luego escribirá la solución 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 personas perezosas para evitar trabajar duro. Incluso los escritores de marcos se reinventan; Todo el framework .Net fue reinventado para hacer lo que COM estaba ofreciendo.

Por más ofensivo que pueda ser para algunos, siempre he encontrado que este término es unclever cuando lo utiliza cualquier forma de ingeniero o en referencia a un tema de creación o diseño de cosas. De hecho, no puedo dejar de verlo como falso al considerar las presiones para innovar en el mundo acelerado de hoy. Repetirte a ti mismo (o ignorar soluciones preexistentes adecuadas) nunca es sabio, pero en realidad, hay una razón por la que no todos seguimos mirando pantallas negras llenas de letras verdes.

Entiendo "Si no está roto, no lo arregles", aunque creo que esa frase puede parecer ignorante para algunos. Sin embargo, con el esfuerzo actual por reinventar la rueda para las necesidades de los viajes espaciales, las carreras, el envío, etc., "no reinventar la rueda" también es bastante ignorante y no es tan inteligente como suena.

Mi experiencia consiste en liderar muchos proyectos y tuve que trabajar con muchos pasantes y otras formas de desarrolladores verdes, y tuve que manejar muchas preguntas ingenuas que algunos llamarían "estúpidas", y también tuve que desviar a las personas. de perseguir a los conejos fuera del alcance de sus tareas. Sin embargo, nunca desalentaría la innovación o la creatividad, y he visto grandes cosas que vienen 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 no es realmente necesario
2. Si es el otro chico que lo está haciendo cuando podrías haberlo hecho

Editar: Puedo ver, por los votos caídos, que debo haber ofendido a algunos. Lo único que me gustaría agregar es que esta frase siempre ha sido mi principal motivo de preocupación. Entiendo que mis dos centavos pueden sonar trollish, pero no tengo intenciones de troll, causar incendios o ofender.

Los argumentos sobre "reinventar una rueda" a menudo se usan en el contexto incorrecto de la elección de usar una biblioteca, pero no es algo similar.

Digamos que estoy evaluando una biblioteca 'forms-plus', que recientemente se hizo popular y ayuda a manejar los formularios. Tiene una bonita página de destino, modernos gráficos geniales y un -culto- (oops me refiero a comunidad) a su alrededor que juran cómo hace que las formas vuelvan a ser geniales de nuevo. Pero "formas más" es una abstracción sobre "formas". Las "formas" eran posibles pero difíciles 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 ruedas. Es más como un nuevo dispositivo de control y un nuevo manual para cualquier dispositivo que ya sea muy complicado que necesita para ejecutar.

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

Después de evaluar cuidadosamente los beneficios y aspectos negativos del uso de una nueva forma de abstracción "formas más" en lugar de usar huesos desnudos "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" de huesos. Tal vez más tarde en el tiempo, más formas había ganado más movimiento detrás de él y se había convertido 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 lo que hace Forms Plus ahora. Las personas que lleguen en este momento serán atraídas a criticar que estoy interesado en reinventar la rueda y debería haber usado la biblioteca existente en su lugar. Pero también es posible que en el momento en que tuve que tomar una decisión sobre "formas más", también existieran muchas otras alternativas a "formas más", la mayoría de ellos proyectos muertos en este momento, y posiblemente gané al no elegir el mal. uno.

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: enlace

En mi experiencia, reinventar ha sido realmente genial, aunque muy largo y tedioso. Diría que, si no sabe 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 hacer algo rápidamente, probablemente solo desee investigar un poco y encontrar el software adecuado para usted.