¿La reutilización en el desarrollo de software es una broma?

Acabo de instalar un módulo a través de npm para un proyecto node.js. Tiene todas sus dependencias. ¡Guauu! Muchos directorios, la mayoría de los cuales nunca tendré que saber. Pero, los módulos son mantenidos por individuos o equipos separados. Eso es reusabilidad.

Por supuesto, hay bibliotecas que implementan algoritmos interesantes. He trabajado para chicos que, debido a algún tipo de enfermedad, reescribieron bibliotecas completas para que pudieran hacer todo en un idioma en su proyecto. Pero, las bibliotecas que reescribieron podrían haberse incluido fácilmente como bibliotecas C o C ++ debajo de su lenguaje favorito.

Hubo un caso en el que el tipo escribió todo en Java. Mientras revisaba el código, me di cuenta de que alguien reemplazaba secretamente sus expresiones regulares reescritas con una biblioteca sólida de C ++ porque la compañía no estaba haciendo afirmaciones de rendimiento. Le mencioné eso al tipo que respondió exigiendo que todo se hubiera hecho en Java y que yo era simplemente estúpido. Bueno, la compañía casi fue cerrada por Oracle por el uso de Java en dispositivos. Los muchachos no habían pagado la tarifa de la licencia. Y, esa fue solo una de las cosas trágicas de esa compañía. Me despidieron por incompetencia. Había estado usando bibliotecas C ++ disponibles gratuitamente para probar algunas cosas nuevas que habrían mejorado su proceso. Es decir, el software de trabajo creado con las horas de trabajo reducidas de la investigación de bibliotecas y el uso de ellas se consideró incompetente por el tipo que reescribió todo en Java por el motivo que sea.

Entonces, la reutilización del código es real. Si se hace correctamente, no volverá a escribir todo lo que se ha escrito, usará las bibliotecas más eficientes y, como resultado, logrará su resultado con la menor cantidad de ataque a su salud.

Ahora, hay veces que lo que quieres no existe. Por lo tanto, puede comenzar sin admitir bibliotecas. Pero, eso no es lo mismo que reescribir, es solo un camino más largo. A veces hay cambios en la arquitectura, por ejemplo, en el hardware, y desea construir sobre eso. Puede portar (no reescribir per se) una biblioteca al nuevo hardware.

He visto muchachos que tienen implementaciones de hardware para las bibliotecas de cadenas que se pueden encontrar en el estándar C. Si quieres ir rápido, puedes usar eso en lugar de la biblioteca estándar realizada en el software. Pero, este es un tipo de reutilización con cierta complejidad adicional.

Las empresas que no planean la reutilización básicamente se están disparando en el pie.

Desde una perspectiva técnica o estratégica, la reutilización está lejos de ser una broma en la programación, ya que incluso un nuevo alumno no querría escribir “hola mundo” dos veces o más. Supongo que estas preguntas surgieron del contexto: si la reutilización es parte del principio de programación, ¿por qué hay tanta versión, revisión y la vida útil relativamente corta de las herramientas o marcos de software?

En software, la reutilización siempre va acompañada de compatibilidad con versiones anteriores, pero a veces, contra la innovación / introducción de nuevos elementos. Tomemos como ejemplo el sistema operativo Windows, cuando se introdujo Windows 95 en ese entonces, mucha gente espera una nueva plataforma pura de 32 bits. Pero resultó que simplemente abrió una puerta al mundo de 32 bits, mientras que más de la mitad del núcleo todavía usa 16 bits. ¿Por qué este anti-clímax? Debido a la compatibilidad con versiones anteriores, como una manifestación de reutilización de la antigua API. La reutilización, si bien es conveniente, siempre hereda la característica (debilidad) de sus fuentes. A Micosoft le tomó algunas iteraciones de Windows (Win 98, Win Me, Win XP) alcanzar un nivel en el que los principales procesos del sistema operativo se ejecutan en 32 bits.

En cuanto a la arquitectura, puede reutilizar tanto hasta el punto que necesita separarse para pasar a un nuevo nivel.

Hasta qué punto parece una broma depende de la tecnología y las promesas que dio. Microsoft promovió una vez DAO (objeto de acceso a datos) como su API de modelado y acceso a datos, pero se cambió a usar ADO en breve. Para mí esto podría ser una broma. Microsoft Internet Explorer ha dejado de crecer en la Versión 11 y reemplazado por Edge. Esto es más ego que una broma. Quizás se pregunte por qué MS hizo esto tan tarde. Obtuvieron más preocupaciones prácticas más allá del software, es decir, identidad, base de clientes heredada, requisitos comerciales, dependencias del producto, etc. ¿Los códigos de IE se transfirieron a Edge? Puede apostar que lo hará, pero copiar y pegar, es decir, el 30% de los códigos no significa ahorrar un 30% de ahorro de tiempo. Esto nos lleva a las siguientes preguntas.

El éxito de la reutilización depende de cómo uno pueda imaginar los cambios futuros. Desde RPC (llamada a procedimiento remoto) hasta servicios web y microservicios, estamos tratando de hacer que la reutilización del software sea lo suficientemente modular como para soportar la interrupción de la tecnología. Algunos duran más que el otro.

¿Hubo piezas de TI que fueron reutilizables y duraron décadas desde que se introdujeron? Sorprendentemente, mucho. Ejemplo: aplicaciones C ++, sus aplicaciones / juegos DOS y si considera la programación de hardware, la arquitectura x86 duró hasta ahora desde que nació con 8086, e incluso impresionó a algunos contendientes más avanzados (es decir, Power PC, DEC Alpha, Itanium ) como implementación principal.

Principalmente.

Por su naturaleza, cualquier cosa hecha para ser reutilizable ha generalizado los problemas más comunes del artículo. Pero al generalizar esos problemas, ha impuesto una solución que puede no ajustarse a todas las situaciones. El resultado es una solución reutilizable que se interpone en el camino de proporcionar la solución que necesita.

Una buena solución reutilizable debería:

1.) identifique el punto más útil para abstraer el problema. (por ejemplo, si usar una biblioteca de base de datos requiere que ahora entregue un objeto de datos mágico a través de su código para acceder a todos los datos y le impida usar otros métodos de manipulación de datos, eso es malo. Pero si abstrae el problema en el punto de almacenar / recuperar tipos de datos * nativos *, esto será útil en más situaciones).

2.) poder ser fácilmente no utilizado en problemas dentro del mismo proyecto caso por caso. (por ejemplo, jQuery es una gran solución generalizada para manipular el DOM, pero si va a interferir con lo que quiere hacer, es fácil no usarlo. WordPress sería un buen contraejemplo. Una vez que ‘ En una página controlada por WordPress, está en WordPress-land y debe hacer casi todo lo que hace WordPress para evitar romper cosas).

Debido a lo anterior, un buen código reutilizable tiende a identificar problemas más pequeños. A medida que crece el tamaño del problema que se está resolviendo, la forma en que se puede personalizar la solución tiende a reducirse.

En mi experiencia, una solución realmente buena para un problema implica una personalización precisa. Como tal reutilización de código no es un objetivo principal de mucho que construyo. Pero aún no he escuchado a un cliente decir: “No estamos contentos con esta solución que resuelve nuestros problemas perfectamente porque no se puede reutilizar para resolver problemas que aún no tenemos”.

Se necesita trabajo.

Cuando está desarrollando un proyecto, a menudo encuentra cosas que podrían tener usos más amplios. Pero, como los ha implementado, están vinculados al proyecto en cuestión. En los próximos proyectos, puede extraer el código fuente y masajearlo un poco para que encaje. Eso es reutilización, aunque no muy buena reutilización. Pero una vez que lo ha usado varias veces, ha demostrado que tiene valor. Ahora puede gastar recursos para moldearlo en una biblioteca con una interfaz genérica bien diseñada y documentación adecuada.

Ese proceso no es opcional. No es razonable esperar que los desarrolladores creen componentes reutilizables mientras trabajan en un proyecto porque, hasta que hayan trabajado con esos componentes durante un tiempo en varias aplicaciones diferentes, no entienden qué características e interfaces deben tener los componentes. para hacerlos ampliamente reutilizables. Es una pérdida de dinero hacerlos genéricos y documentarlos exhaustivamente cuando se usan una vez en un proyecto en particular. Si lo intentas, terminarás con una biblioteca que no sirve para nada más y nadie la usará.

Pero tampoco puede escribir una biblioteca hasta que sepa lo que debe hacer. Gastar grandes cantidades en un proyecto de biblioteca independiente producirá código que no se ajusta a cómo la gente necesita usarlo. Si lo usan, tendrán que envolverlo en capas de interfaz que toman tiempo para producir y agregar complejidad. Necesita experiencia sobre cómo las características de la biblioteca se ajustan a su entorno específico antes de poder diseñarla. La reutilización informal le brinda ese conocimiento.

Sin embargo, la instrucción de escribir para reutilizar tiene valor. A menos que los desarrolladores estén buscando componentes que tengan aplicaciones más amplias, no escribirán esas primeras implementaciones deficientes que pueden ampliar y mejorar en proyectos posteriores. A menos que estén escribiendo código con esa mentalidad, ni siquiera notarán que están escribiendo lo mismo una y otra vez.

Simplemente no espere que cada proyecto produzca un montón de bibliotecas gratuitas que todo el mundo comienza a usar de inmediato. Si cada uno presenta uno o dos componentes nuevos y vuelve a colocar un par de los escritos anteriormente, eso es todo lo que puede esperar. Realmente hacer la biblioteca es un proyecto en sí mismo. Necesita ser costeado, especificado y dotado de recursos como cualquier otro.

Por supuesto, es posible y vale la pena crear código reutilizable, eso es lo que son las bibliotecas estándar, pero no puede crearlo sin trabajar en él. Esa biblioteca es una inversión, no un regalo.

Encontré una buena generalización sobre la reutilización del código, lo siento, no puedo encontrar el origen:

La reutilización en lo pequeño es un problema resuelto.

La reutilización en general es un problema sin resolver.

Interpreto que esto significa que escribir funciones de bajo nivel para realizar tareas simples es bastante fácil. Por ejemplo:

• Tokenizar una cadena
• Abrir una conexión de base de datos
• Publicar un evento en una cola
• Convierte una cadena en entidades HTML.

Cuanto más específica y clara sea la función, más fácil será hacerla reutilizable para muchas aplicaciones.

Mientras que una función que hace demasiado:

• Diseñe un lienzo de GUI redimensionable
• Autenticar inicio de sesión para una aplicación web
• Fábrica de resúmenes para otros tipos de clases.

Estas tareas son tan amplias y de alto nivel, con una configuración potencial con muchas opciones que no son buenas candidatas para la reutilización del código. Deben ser la “parte superior de la cadena alimentaria” para su código. Estas son sus aplicaciones, que no deben ser reutilizadas por otras aplicaciones.

Si se encuentra tratando de escribir una clase reutilizable que tenga docenas de opciones y rutas de código condicionales, esto debería ser una pista de que necesita descomponer la clase en otras clases, o simplemente dejarla sola y admitir que esta clase es el final.

Depende Si trabaja en una empresa con docenas de desarrolladores, puede encontrar a alguien cuyo trabajo sea crear componentes de IU reutilizables para el resto de los desarrolladores. O, por ejemplo, cuando una empresa se centra en un marco, entonces vale la pena crear componentes reutilizables, que se puedan utilizar en el resto de sus productos.

Si es un profesional independiente, lo más probable es que desarrolle algunos módulos que usará con su marco favorito.

Esas son mis experiencias.

Además, maldito ecosistema de Node.js. Solo observe cuántos componentes diferentes habrá instalado, incluso si necesita explícitamente uno o dos.

Ya hay buenas respuestas y estoy totalmente de acuerdo en que ‘reutilizar en grande’ todavía no es un problema resuelto .

Para agregar a lo que ya se ha dicho, también hay una debilidad en cómo las cosas se vuelven “reutilizables”.

He perdido la cuenta de la cantidad de veces que he visto a alguien escribir un código que claramente se ha escrito miles de veces y está disponible en varias bibliotecas conocidas.

El código abierto ha sido un gran paso hacia un mejor “intercambio” de código, pero incluso eso está fragmentado y todos quieren “hacer lo suyo”.

El problema básico es:

• ¿Cómo concentrar esfuerzos en versiones canónicas?
• ¿Cómo encuentras versiones canónicas cuando las necesitas?

No estoy seguro, pero hay algunos argumentos a favor de los “estándares” como una solución para el primero y otro para IDE, etc. para ayudar con el último.

Esto requiere colaboración a través de las fronteras comerciales. Esto significa que las empresas necesitan ver los beneficios (aunque casi todas las otras ramas de la ingeniería reconocen esto …)

Por cierto … lo que esto también sugiere es que probablemente estés mejor con un software ‘maduro’ y reforzado para la batalla que con cosas de vanguardia si quieres beneficiarte de la reutilización.

Las cosas más antiguas tienen mucho conocimiento capturado; muchas pruebas realizadas; Mucho tiempo de ejecución.

La reutilización en el desarrollo de software ha hecho un enorme progreso en las aproximadamente dos décadas que abarca mi propia carrera. Cuando comencé a trabajar en esta industria, el código abierto era una idea marginal que nadie se tomó en serio. Las plataformas eran propietarias, y más allá de las bibliotecas estándar, cada empresa que lo necesitaba construía todo desde cero.

Ahora, todas las mejores plataformas y herramientas están abiertas, y tenemos redes sociales enteras dedicadas a la colaboración de código. Un proyecto grande típico depende de cientos de componentes reutilizables, de aproximadamente tantos contribuyentes diferentes. Por lo general, son gratuitos y se pueden encontrar a los pocos minutos de saber que los necesita.

Los mejores lenguajes y metodologías de programación también han ayudado con la reutilización, quizás no en la medida en que algunas personas lo imaginaron, pero ciertamente hasta cierto punto. Sin embargo, el verdadero cambio revolucionario han sido los increíbles ecosistemas que han crecido en torno al código abierto e Internet.

Cualquiera que piense que la reutilización del código es una especie de concepto fallido carece de perspectiva. No confundas tus propias frustraciones a corto plazo con la inutilidad a largo plazo.

Mas o menos. Parte del problema es que la mayoría del desarrollo de software tiene lugar en proyectos muy específicos. Diseñar una pieza de software para su reutilización requiere tiempo, reflexión y trabajo de diseño. El mayor problema es tiempo / costo. La mayor parte del desarrollo de software que he realizado tiene lugar en proyectos específicos con un resultado y una fecha límite específicos.

Recuerde, los proyectos son una función de tiempo, costo y calidad. Y obtener un software de “calidad y reutilizable” lleva tiempo. No hay demasiados gerentes de proyecto que estén interesados ​​en que las personas en su proyecto tomen el tiempo / costo para desarrollar software reutilizable que pueda reducir el tiempo en el proyecto de otra persona.

Además … está la parte del ego que tienen los desarrolladores de software sobre el uso del software de otra persona. Y la mayoría de nosotros buscamos el código que nosotros u otra persona hemos usado en otro lugar y modificamos … lo cual es en sí mismo reutilización del código.

Tanto los subsistemas grandes como las pequeñas pepitas de código se reutilizan a diario. La reutilización no es una broma. Es dificil. Hay decenas de miles de bibliotecas de funciones reutilizables. Muchos son pequeños, como zlib. Algunos son enormes, como win32 o android.

Cuanto más grande es una biblioteca reutilizable, más trabajo se debe hacer para que sea coherente, cubra una gran cantidad de casos de uso y documente su función. Cuando las personas esperan reutilizar el software sin hacer un esfuerzo adicional, casi siempre se sienten decepcionadas. Las inconsistencias molestan a los desarrolladores que intentan usar una biblioteca, por lo que la abandonan. Las bibliotecas que no cubren muchos casos de uso no son lo suficientemente útiles como para que valga la pena aprenderlas. Una gran biblioteca indocumentada es como las selvas de África, oscura, peligrosa e impenetrable. (Las literarias del siglo XIX, no las selvas reales, reales).

La reutilización es más un problema social que un problema técnico. Dentro de una organización, debe ser consciente de la fuerte subida que las personas asumen cuando intentan usar algo diseñado por otro equipo.

La técnica que he encontrado más útil es asegurarme de que las personas vengan con el software. Si hay un objetivo organizacional para usar una pieza de código particular en otro equipo, no hay nada mejor que algunos de los desarrolladores originales trabajen con el nuevo grupo que está intentando usarlo.

La reutilización de código es una de las mejores metodologías de programación que ayuda a los programadores a implementar código fuente bien estructurado y manejable.

La ilustración básica de la reutilización del código es la biblioteca de base de datos que forma parte del marco de código.

Definimos una clase de biblioteca de base de datos común que consta de funciones de operaciones de base de datos y, a través de la biblioteca de referencia en un script, reutilizamos esas funciones para la implementación de las características de la aplicación.

Encuentro muchas de las respuestas … desconcertantes. Claro, objetos y bibliotecas y marcos, bla, bla, pero la mayoría parece haber olvidado una tendencia que realmente resuelve muchos de los problemas de reutilización, que son API abiertas, que es una especie de enlace dinámico en bits de código que se generaliza , que usted adapta a sus necesidades. Claro, las bibliotecas y los objetos compartidos * pueden * hacer eso, sin embargo, las limitaciones de velocidad, tamaño y otros problemas del servidor localizados han sido un obstáculo durante años y años. Mejores velocidades de red y almacenamiento en caché inteligente realmente está resolviendo el problema de manera inteligente. Es posible que algunos de ustedes hayan oído hablar de esta nueva nube en la que están trabajando … Y están trabajando en ello por esta misma razón. La verdadera promesa de la nube es la reutilización.

Habiendo dicho todo eso, todavía me sorprende la cantidad de código que se está inventando una y otra vez. * suspiro * Todos quieren ser genios …

¿Qué es reutilizar?

La reutilización es un principio por el cual buscamos tomar un código existente, diseñado con una aplicación específica en mente y usarlo nuevamente en un contexto diferente, tal vez incluso para un propósito diferente.

¿Qué es un propósito?

Para esta discusión, nos referiremos al propósito como la razón por la cual un fragmento de código fue implementado de cierta manera para ser utilizado por la aplicación .

Para entender lo que esto significa, suponga que tiene un carrito de compras: para guardar cada artículo en el carrito, probablemente quiera usar una lista de algún tipo.

Pero una lista también se puede usar para otras cosas, como guardar todos los artículos en un periódico, capítulos en un libro, etc. Si lo piensas bien, los artículos en un periódico y los capítulos en un libro no son tan diferentes: ¿tal vez comparten un antepasado? Sin embargo, aquí es donde las cosas se matizan: si compartían un antepasado, entonces podría incluir un artículo en una página de libro. Y puede hacerlo, siempre y cuando solo se refiera al texto: pero un periódico tiene, en general, un formato de página diferente. por lo que no puede adjuntar fácilmente una página de periódico a un libro.

Vea cómo ahora esto se está volviendo bastante complejo allí: entonces, la noción de un artículo y la de los contenidos de una página de libro son similares, pero el medio al que estamos acostumbrados para leerlos es significativamente diferente.

Así que ahora llegamos a la idea de un modelo y una vista: el contenido de una página es el modelo, pero cómo se presenta ese contenido es una vista. Lo que parecía una situación bastante simple ahora se ha vuelto muy matizado y nada fácil.

El mayor problema con la reutilización es determinar qué se puede reutilizar de forma segura

¿Qué es precisamente lo que te propusiste reutilizar? ¿Estás seguro de que lo que te propusiste reutilizar tiene sentido?

Hasta ahora hemos establecido que el contenido de un artículo de periódico y una página de un libro son intercambiables, ¿verdad? Pues sí y no. El problema es que con demasiada frecuencia un artículo puede tener fotos que son específicas para la página de un periódico y no pueden adaptarse fácilmente para un libro. Por lo tanto, ahora necesita un método para asegurarse de que el contenido se mostrará de manera correcta en la página del libro y, si no es así , debe copiar el contenido para que pueda modificarse .

Como puede ver, incluso las cosas que son conceptualmente muy simples todavía tienen muchos matices. Ese es el problema con la reutilización.

Había una vez la creencia de que el software orientado a objetos produciría más reutilización porque la clase era un componente autónomo que, si se escribía correctamente, tendría utilidad en muchos lugares.

Eso realmente no ha sucedido.

A nivel de clase, la reutilización no sucedió, pero sí a nivel de marco.

Casi todos los desarrolladores modernos comenzarán a trabajar tomando algunos marcos. Y si están haciendo tipos similares de trabajo, a menudo encapsularán sus propias cosas en un marco propio.

La reutilización definitivamente no es una broma. El problema es que se basa en un conjunto particular de habilidades. Si tiene una sólida comprensión de los principios SOLID, le resultará mucho más fácil escribir código reutilizable.

Además, distribuir código reutilizable es más fácil que nunca. Herramientas como NPM, Nuget e incluso Bower. Todas estas herramientas son testimonio de cómo se ha convertido el código reutilizable.

Creo que en esta era de GitHub y BitBucket, la reutilización está en su punto más alto. Para una gran cantidad de desarrollo, la mayoría de los desarrolladores utilizarán marcos y bibliotecas de código abierto gratuitos.

Y estos marcos no son solitarios desarrolladores que dan a la comunidad. Hay muchas compañías como Microsoft, Twitter, Google, EBay, KickStarter que están regalando su software.

No, la legibilidad en el desarrollo de software no es una broma. Es un principio de metodología de desarrollo de software que lo guía en la arquitectura. Las personas que dicen que es un fracaso son generalmente aquellas que toman el principio como una regla difícil. No hay reglas estrictas en el desarrollo de software, solo las mejores prácticas por las que debe luchar, pero que pueden diferir cuando sea necesario.

La falta de reutilización es la característica de los malos jefes.

1. El código creado debe ser de alta calidad. Los jefes no deben permitir que los errores permanezcan en el código, deben forzar que el código sea simple y reutilizable.
2. Los programadores deben ser recompensados ​​no por los detalles, ni por sus inventos, ni por las líneas de código, el número de clases, los métodos que crean, las tareas que resuelven. Deben ser recompensados ​​por lo simple, lo rápido, lo libre de errores, lo satisfactorio que crean para los usuarios finales. El impulso debe estar en la reutilización del código para ahorrar tiempo de recreación, depuración, prueba …
3. La mayoría de las personas tienden a disfrutar a través de los medios más simples disponibles. Por ejemplo, los programadores tienden a jugar creando código complejo, difícil de entender y muy compacto (que no es bueno para reutilizar). Una vez más, es tarea de los jefes construir una cultura que obligue a las personas a disfrutar de los resultados finales y no de los pequeños pasos.

Sí, la mayoría de las empresas lo consideran una broma. La mayoría de las empresas tienen malos jefes. La mayoría de las empresas no logran proporcionar valor continuo.