¿Qué cuenta como reinventar la rueda?

¿Los siguientes escenarios cuentan como "reinventar la rueda" en su libro?

• Existe una solución, pero no en el idioma que desea usar, y las soluciones existentes no pueden interactuar con el idioma que desea usar de una manera limpia e idiomática.

• En principio, podría obtener una biblioteca existente para hacer lo que quisiera con grandes modificaciones, pero cree que probablemente sería más fácil comenzar desde cero.

• Lo que está escribiendo tiene la misma descripción de una línea que las cosas que ya se han hecho, pero está apuntando a un nicho diferente. Por ejemplo, tal vez su problema se haya resuelto miles de veces antes, pero de una manera que es ineficiente para grandes conjuntos de datos y su código funciona bien para grandes conjuntos de datos.

Si hay una solución existente que a sus ojos sería una solución práctica , entonces no usarla sino crear su propia solución sería reinventar la rueda. Aparte de eso, es altamente subjetivo.

Sobre sus escenarios específicos:

1. Siempre desea un código limpio, fácil de mantener y fácil de entender. Eso va más allá de reinventar la rueda, en mi humilde opinión. Sin embargo, la restricción de tiempo puede hacer que quieras romper esto.
2. Si es más fácil comenzar desde cero, hágalo. Probablemente también obtendrá un mejor resultado si el código fue diseñado para la necesidad específica.
3. Si una solución es una mala solución para su problema, no es reinventar la rueda para crear una nueva, sino hacer una rueda mejor .

Reinventar la rueda es de lo que otros te acusan cuando tu análisis indica que debes escribir algo tú mismo y el suyo no.

Creo que reinventar la rueda se puede definir de manera bastante simple: cuando, a la larga, haces más trabajo escribiéndolo tú mismo en lugar de usar la biblioteca. Tenga en cuenta que no siempre está claro cuánto trabajo puede ser algo a largo plazo . Es posible que pueda hackear un prototipo usted mismo más rápido de lo que puede refactorizar su código existente para incluir la biblioteca, pero, a la larga, cuando agrega más capacidades o tiene que admitir el código, la biblioteca funcionaría mejor.

La conclusión es que debe pensar detenidamente sobre su situación al decidir si usar o no una biblioteca. Debe decidir si la biblioteca es más fácil para lo que quiere hacer ahora y más fácil para lo que hará en el futuro . Saber lo que hará en el futuro no siempre es sencillo, pero si tiene un buen plan, debe tener una idea aproximada. Dicho esto, a veces los pronósticos son inexactos: generalmente no te das cuenta de que has reinventado la rueda hasta después de haberla hecho.

Es demasiado amplio y subjetivo para ser posible responder con precisión simplemente porque cada caso es diferente.

Es perfectamente aceptable reinventar la rueda cuando sea necesario, la clave es usar su criterio para decidir cuándo la rueda anterior es una solución aceptable y cuándo no es lo suficientemente redonda como para dar un paseo suave.

Es una pregunta que debe hacerse casi retóricamente a veces para garantizar que se utilice el mejor enfoque. A menudo puede encontrar un mejor algoritmo en un libro que la mayoría de los programadores pueden escribir en el tiempo que lleva encontrarlo.

Cuanto más grande y complejo sea el problema, es menos probable que exista una rueda que se adapte exactamente a sus necesidades, y más legítimo será reconstruirla.

Creo que solo deberíamos aplicar "no reinventar la rueda" a elementos básicos (funciones que ya están integradas en la plataforma, patrones de diseño conocidos ...) o si la solución exacta a su problema está disponible, pero eso es Raramente el caso.

Tus 3 puntos no cuentan como reinventar la rueda para mí.

Depende ...

Para los dos primeros:

• Existe una solución, pero no en el idioma que desea usar ...
• En principio, podría obtener una biblioteca existente para hacer lo que quisiera con grandes modificaciones ...

En ambos casos, tiene sentido escribir su propio código. Pero considere esto: ¿contiene la solución existente alguna técnica, algoritmo o rutina de la que pueda aprender? Ignorarlos sería reinventar la rueda.

• Lo que está escribiendo tiene la misma descripción de una línea que las cosas que ya se han hecho ... tal vez su problema se haya resuelto un millón de veces antes, pero de una manera que es ineficiente para grandes conjuntos de datos ...

Tres preguntas:

1. Un trillón es mucho. ¿ Realmente has mirado todas las implementaciones existentes?
2. ¿Es la eficiencia su principal problema?
3. ¿Necesita codificar la solución óptima ahora (y volver a escribir más tarde)?

Si la respuesta a cualquiera de estas preguntas es "No", está reinventando la rueda.

Dicho esto, no estoy convencido de que reinventar la rueda siempre sea ​​algo malo de todos modos:

1. Es una excelente manera de aprender , y la única forma de comprender realmente las soluciones existentes.
2. Las ruedas de otras personas pueden no ser buenas . Es la única forma de hacer mejores ruedas.
3. Incluso si las ruedas de otras personas son geniales, a veces puedes hacer buenos negocios haciendo ruedas aún mejores .

Su primer escenario, se aplica para reinventar la rueda, se explica por sí mismo.

El segundo escenario, NO se aplica si el código existente requiere poca modificación, pero si lo hace, es una buena idea intentar usar propiedades, métodos y usos similares a los de un código existente, para que otros desarrolladores no tengan problemas para usar su "rueda".

Tenga cuidado con el enfoque "siempre es mejor comenzar desde el comienzo", puede llevar más tiempo del esperado.

El tercer escenario que mencionas es el enfoque "práctico". La "rueda dada" puede hacer el trabajo, pero, en realidad, consume demasiados recursos, memoria, velocidad, etc.

Trabajé una vez en una aplicación que requiere mostrar datos jerárquicos en un control de vista de árbol desde una sola tabla. Ya tenemos un control que podría hacer eso, pero admitimos varias tablas, por elemento.

Para usarlo, tuve que aprender demasiadas cosas, asignar demasiadas propiedades, ejecutar demasiados métodos, y FUE LENTO. Un compañero de trabajo insistió en usarlo para "no reinventar la rueda".

Hice un nuevo control, desde cero, leí una sola tabla, programé solo algunas propiedades fáciles de aprender. Y antes de darme cuenta, hubo otro compañero de trabajo que lo tomó del repositorio de código compartido y reemplazó el control anterior.

Prima:

Cuando la rueda que ya tienes está "al cuadrado". Por "cuadrado", quiero decir que en la superficie, parece que parece una solución a su problema, pero después de una buena mirada, llega a la conclusión de que no.

Depende de si tiene las habilidades y el tiempo (y la autorización de su empresa) para reinventar la rueda.

Primero lea este excelente artículo de Joel Spolsky: En defensa del síndrome de no inventado aquí

Entonces, todas las razones técnicas se convierten en matices realmente menores. Si cree que este software es crítico para su trabajo, vuelva a escribirlo. Sí, es "reinventar la rueda", pero probablemente valga la pena pasar tiempo escribiendo y manteniendo. Si no es crítico, simplemente use lo que está disponible.

... si alguna vez ha tenido que externalizar una función comercial crítica, se dará cuenta de que la externalización es un infierno. Sin un control directo sobre el servicio al cliente, obtendrá un servicio al cliente terriblemente malo, del tipo del que las personas escriben en sus blogs cuando intentan conseguir que alguien, cualquier persona , de alguna compañía telefónica haga lo más básico. Si externaliza el cumplimiento, y su socio de cumplimiento tiene una idea diferente sobre lo que constituye la entrega rápida, sus clientes no estarán contentos y no hay nada que pueda hacer al respecto, porque le tomó 3 meses encontrar un socio de cumplimiento en el primero lugar, y de hecho, ni siquiera sabrásque sus clientes no están contentos, porque no pueden hablar con usted, porque ha establecido un centro de servicio al cliente externo con el objetivo explícito de no escuchar a sus propios clientes. ¿Ese motor de comercio electrónico que compraste? No hay forma de que sea tan flexible como lo que Amazon hace con los obidos, que escribieron ellos mismos. (Y si es así, entonces Amazon no tiene ventaja sobre sus competidores que compraron lo mismo). Y ningún servidor web estándar será tan rápido como lo que Google hace con su servidor codificado a mano y optimizado a mano.

Este principio, desafortunadamente, parece estar directamente en conflicto con el ideal de "reutilizar el código bien - reinventar la rueda mal".

El mejor consejo que puedo ofrecer:

    Si se trata de una función comercial central, hágalo usted mismo, pase lo que pase.

Elija sus competencias y objetivos comerciales principales, y haga los de la casa ...

Si está desarrollando un juego de computadora donde la trama es su ventaja competitiva, está bien usar una biblioteca 3D de terceros. Pero si los efectos 3D geniales van a ser su característica distintiva, es mejor que haga su propio ...