Muy a menudo hay que cumplir con la recomendación "no reinventar la rueda". A veces con pronunciada negligencia y autoafirmación, a veces, aparentemente , como un buen consejo. Sin embargo, incluso si fue llamado para ser un buen consejo, en varios contextos solo muestra la incompetencia del hablante.
El propósito anidado de la frase es salvarlo del trabajo inútil, la llamada a usar una solución preparada para la tarea y, desde el punto de vista de un observador externo, realmente parece razonable.
Pero al mismo tiempo, se pierde un factor clave que es característico no solo para desarrollar software, sino también para resolver cualquier problema : al cambiar el contexto en el que se establece la tarea, la solución también cambia .
Perder de vista este principio es lo mismo que admitir su propia incapacidad para resolver problemas aplicados.
Considere algunos casos.
Fuente
API sobre API
Uno de los casos comunes de acusaciones de ciclismo es el contenedor de API de auto escritura de algún servicio, cuya implementación ya está disponible.
Un caso de mi práctica.
Fue necesario implementar la carga de datos de Facebook a nuestro servicio. El lenguaje principal y la biblioteca de Facebook se buscaron en Google en 2 minutos.
La documentación de la biblioteca no se correspondía con la interfaz del programa actual , se envolvieron muchas acciones innecesarias alrededor de cada manipulación. La biblioteca resultó ser de muy mala calidad .
Resultado: después de 1,5 horas de trabajo con él, ni siquiera fue posible iniciar sesión.
Un colega implementó su propio contenedor de API web de Facebook. En total, le llevó aproximadamente una hora crear un contenedor y la funcionalidad relacionada en el lado del servicio. A la pregunta "por qué estás en bicicleta aquí" , respondió los próximos días.
Esto es especialmente evidente en los idiomas principales con una gran comunidad: existe una tendencia poco saludable a publicar contenedores API sobre otra API, bajo los lemas "Para humanos" y "De una manera simple". Tales envolturas se vuelven obsoletas tan pronto como se actualiza la interfaz envuelta, y los autores abandonan tales "proyectos", haciendo que el código que los usa no funcione.
Una buena pregunta : ¿y qué, cada vez que escriba tales envoltorios manualmente?
Respuesta: Una solución mucho más sólida para envoltorios grandes sería usar un generador de código que interprete las especificaciones.
Control sobre la base del código y negativa a responder por los errores de otros.
En los círculos de aspirantes al desarrollo de juegos de computadora, esta frase está dirigida a cualquiera que se atreva a implementar su motor. "¿Por qué reinventar la rueda? ¡Toma la unidad!" . O Game Maker, o, Dios no lo quiera, Defold.
Parece que dviglo \ constructor proporciona todas las herramientas necesarias para el desarrollo, muchas de ellas multiplataforma y, en general, simplifican la vida.
¿Cómo debería cambiar el contexto aquí para que sea necesario hacer tu propio motor?
Como mínimo, este es el control sobre la base del código y las funciones del motor (por ejemplo, en varios modelos de controlador, el creador del juego tiene errores constantemente, y arreglar esto puede ser extremadamente problemático). Es decir, es necesario reducir la probabilidad de encontrar un "error extraño" , que es imposible o extremadamente difícil de solucionar por sí solo.
Esto es especialmente pronunciado en los juegos que no están saturados de campanas y silbidos gráficos y / o físicos, cursi, no tanto como el motor condicional se hace cargo.
Además, no es necesario aumentar la cantidad total de la base de código si se usa una pequeña parte de sus funciones del motor / constructor, y las herramientas necesarias aún deben agregarse de forma independiente , controlando simultáneamente la corrección de su trabajo con el motor.
Por ejemplo, basado en tales premisas, Tommy Refenes escribió su propio motor para Super Meat Boy .
Alguien se opondrá: "¡Pero en el almacén \ algún otro almacenamiento, hay una montaña de presets \ herramientas \ extensiones!" .
Sí, es maravilloso y ofrece un par de puntos por delante, pero en los motores con una gran base de usuarios activos, se observa el mismo efecto "morir joven" descrito en la sección anterior. Sin un contexto y una tarea específica, no se puede afirmar inequívocamente que, de, la abundancia de extensiones personalizadas en la tienda jugará en las manos.
Identidad imaginaria Tirando de la tarea por las orejas.
A veces, una vez formulado el problema, resulta que las soluciones existentes que se me ocurren ... no son adecuadas. Debido a su "contenido de grasa" o la insatisfacción de una de las condiciones clave de la tarea ( sí, hay varias ).
Buen ejemplo: CluNet.
Cluster en su artículo describió completamente las razones de las decisiones tomadas por él al desarrollar el protocolo de hogar inteligente. El ejemplo es muy revelador y está bien descrito. Recomiendo desmontarlo usted mismo.
Conclusión
Al buscar una solución a un problema , se debe considerar el contexto y todas las condiciones dadas .
Incluso en casos simples, pequeños detalles del contexto ponen la solución al revés, y la habilidad de resolver problemas aplicados se basa en gran medida en la capacidad de ver y evaluar las premisas iniciales .
Entonces, ¿dice la frase "no reinventar la rueda" sobre la incapacidad del asesor para resolver problemas? Si el asesor mencionó las bicicletas antes de dudar después de unos minutos, lo más probable es que sí.
O, en generalización del capitán:
Piensa antes de decidir.
Piensa antes de hablar.
Y en general, piensa.