components - reutilizacion - ¿Hemos renunciado a la idea de la reutilización del código?

reutilizacion de codigo poo (16)

Hace un par de años, los medios estaban llenos de todo tipo de artículos sobre cómo la idea de la reutilización de códigos era una forma simple de mejorar la productividad y la calidad del código.

De los blogs y sitios que reviso regularmente, parece como si la idea de "reutilización de código" hubiera pasado de moda. ¿Quizás los defensores de la "reutilización del código" se hayan unido a la multitud de SOA? :-)

Curiosamente, cuando buscas "reutilización del código" en Google, el segundo resultado se titula:

"¡Reutilización interna del código considerada peligrosa"!

Para mí, la idea de la reutilización de código es solo sentido común, después de todo, ¡mira el éxito del proyecto de apache commons!

Lo que quiero saber es:

¿Usted o su empresa intentan reutilizar el código?
En caso afirmativo, ¿cómo y en qué nivel, es decir, api de bajo nivel, componentes o lógica comercial compartida? ¿Cómo usan usted o su empresa el código de reutilización?
¿Funciona?

¿Discutir?

Soy plenamente consciente de que hay muchas librerías de código abierto disponibles y que cualquiera que haya usado .NET o JAVA ha reutilizado el código de alguna forma. ¡Eso es sentido común!

Me refería más a la reutilización de código dentro de una organización que a través de una comunidad a través de una biblioteca compartida, etc.

Originalmente pregunté;

¿Usted o su empresa intentan reutilizar el código?
En caso afirmativo, ¿cómo y en qué nivel, es decir, api de bajo nivel, componentes o lógica comercial compartida? ¿Cómo usan usted o su empresa el código de reutilización?

Desde donde estoy sentado, veo muy pocos ejemplos de compañías que intentan reutilizar el código internamente.

Si tiene un fragmento de código que podría compartirse potencialmente en una organización de tamaño mediano, ¿cómo informaría a otros miembros de la empresa que este lib / api / etc. existía y podría ser beneficioso?

Creo que la falta de "atención de los medios" se debe al hecho de que todos lo están haciendo, por lo que ya no vale la pena escribir sobre él. No escucho a tanta gente crear conciencia sobre la programación orientada a objetos y la prueba de unidad como solía hacerlo. Todos ya conocen estos conceptos (ya sea que los usen o no).

Creo que la reutilización de código se está haciendo a través de proyectos de código abierto en su mayor parte. Todo lo que puede reutilizarse o ampliarse se realiza a través de bibliotecas. Java tiene una increíble cantidad de bibliotecas de código abierto disponibles para hacer una gran cantidad de cosas. Compare eso con C ++, y qué tan temprano tendría que implementarse todo desde cero utilizando MFC o la API de Win32.

El título del artículo al que se refiere es engañoso, y en realidad es una muy buena lectura. La reutilización de código es muy beneficiosa, pero hay inconvenientes con todo. Básicamente, si no recuerdo mal, la esencia del artículo es que estás sellando el código en una caja negra y no revisándolo, de modo que cuando los desarrolladores originales te dejan, pierdes el conocimiento. Si bien entiendo el punto, no estoy necesariamente de acuerdo con él, al menos no con la idea de que "el cielo está cayendo".

En realidad, agrupamos la reutilización de código en más que solo clases reutilizables, observamos toda la empresa. Las cosas que se parecen más a la mejora del marco o abordan las preocupaciones transversales se ponen en un marco de desarrollo que todas nuestras aplicaciones usan (piense en cosas como la validación previa y posterior, el registro, etc.). También tenemos lógica de negocios que se aplica a más de una aplicación, por lo que ese tipo de cosas se mueven a un núcleo de BAL accesible en cualquier lugar.

Creo que lo importante no es promover cosas para su reutilización si no se van a reutilizar realmente. Deben estar bien documentados, para que los nuevos desarrolladores puedan tener un recurso que les ayude a acelerar también. Lo más probable es que, si el conocimiento no se comparte, el código eventualmente se reinventará en otro lugar y dará lugar a la duplicación si no es riguroso en la documentación y el intercambio de conocimientos.

La idea de la reutilización del código ya no es una idea nueva ... de ahí la aparente falta de interés. Pero todavía es una gran idea. Todo el framework .NET y la API de Java son buenos ejemplos de reutilización de código en acción.

Nos hemos acostumbrado a desarrollar bibliotecas OO de código para nuestros proyectos y a reutilizarlos en otros proyectos. Es una parte del ciclo de vida natural de una idea. Se debate acaloradamente durante un tiempo y luego todos aceptan y no hay motivo para una discusión posterior.

La reutilización de código es esencial. Encuentro que también me obliga a generalizar tanto como sea posible, también haciendo que el código sea más adaptable a situaciones variables. Idealmente, casi todas las bibliotecas de nivel inferior que escriba deberían ser capaces de adaptarse a un nuevo conjunto de requisitos para una aplicación diferente.

Los dos proyectos de software en los que he trabajado han sido desarrollo a largo plazo. Uno tiene alrededor de 10 años, el otro ha existido por más de 30 años, reescrito en un par de versiones de Fortran en el camino. Ambos hacen una extensa reutilización del código, pero ambos dependen muy poco de herramientas externas o bibliotecas de códigos. DRY es un gran mantra en el proyecto más nuevo, que está en C ++ y se presta más fácilmente para hacerlo en la práctica.

Por supuesto, reutilizamos el código.

Hay una cantidad casi infinita de paquetes, bibliotecas y objetos compartidos disponibles para todos los idiomas, con comunidades enteras de desarrolladores pidiéndoles apoyo y actualización.

Quizás la mejor pregunta es ¿cuándo NO reutilizamos el código en estos días? Estamos en un estado de construcción usando otras personas observando las "mejores prácticas" o "patrones de diseño" previamente descubiertos o simplemente construyendo sobre el código heredado, bibliotecas o copias.

Parece que el grado en que se reutiliza el código A para hacer el código B a menudo se basa en cuánto se abstraen las ideas en el código A tomadas del código B en patrones de diseño / modismos / libros / pensamientos fugaces / código real / bibliotecas. La parte más difícil es aplicar todas esas buenas ideas a tu código real.

Los tipos no técnicos se vuelven demasiado entusiastas sobre la reutilización. No entienden por qué no se puede copiar y pegar todo. No entienden por qué el greemelfarm necesita un adaptador especial para comunicar la misma información que solía al sistema anterior al nuevo sistema, y que, desafortunadamente, tampoco podemos cambiar debido a un millón de otras razones.

Creo que los técnicos han estado reutilizando desde el día 1 de la misma manera que los músicos han estado reutilizando desde el día 1. Es una evolución orgánica continua y una síntesis que continuará.

Reutilizamos el código.

A pequeña escala, tratamos de evitar la duplicación de código tanto como sea posible. Y tenemos una biblioteca completa con muchos códigos de uso frecuente.

Normalmente el código se desarrolla para una aplicación. Y si es lo suficientemente genérico, se promociona a la biblioteca. Esto funciona excelente

Reutilizamos el código; de hecho, nuestros desarrolladores escriben código específicamente que se puede reutilizar en otros proyectos. Esto ha funcionado bastante bien: podemos comenzar nuevos proyectos rápidamente y endurecemos iterativamente nuestras bibliotecas centrales.

Pero uno no puede simplemente escribir código y esperar que se reutilice; la reutilización del código requiere comunicación entre los miembros del equipo y otros usuarios para que la gente sepa qué código está disponible y cómo usarlo.

Se necesitan las siguientes cosas para que la reutilización de código funcione de manera efectiva:

El código o la biblioteca en sí
Demanda del código en múltiples proyectos o esfuerzos
Comunicación de las características / capacidades del código
Instrucciones sobre cómo usar el código
Un compromiso para mantener y mejorar el código a lo largo del tiempo

Si bien creo que la reutilización de código es valiosa, puedo ver dónde se enraiza este sentimiento. He trabajado en muchos proyectos en los que se tuvo mucho más cuidado para crear código reutilizable que luego nunca se reutilizó. Por supuesto, la reutilización es mucho más preferible que duplicar el código, pero he visto muchos modelos de objetos muy exhaustivos creados con el objetivo de utilizar los objetos en toda la empresa en múltiples proyectos (la forma en que se puede usar el mismo servicio en SOA en diferentes aplicaciones) pero nunca han visto los objetos realmente usados más de una vez. Tal vez simplemente no he sido parte de organizaciones que aprovechan el principio de reutilización.

El nivel de atención de los medios a un problema tiene poco que ver con su importancia, ya sea que estemos hablando de desarrollo de software o de política. Es importante evitar perder el esfuerzo de desarrollo reinventando (o re-manteniendo) la rueda, pero esto es tan conocido ahora que un editor probablemente no se entusiasme con otro artículo sobre el tema.

En lugar de mirar el número de artículos actuales y publicaciones de blog como una medida de importancia (o urgencia) observe los conceptos y las frases de moda que se han convertido en clásicos o ingresado a la jerga (¡otra forma de reutilización!) Por ejemplo, Google para usos del acrónimo DRY para una buena discusión sobre las muchas formas de redundancia que pueden eliminarse en el software y los procesos de desarrollo.

También hay un papel para el juicio maduro con respecto a los costos de reutilización frente a donde se logran los beneficios. Algunos escritores abogan por esperar a preocuparse por la reutilización hasta que aparezca un segundo o tercer uso, en lugar de gastar esfuerzos para generalizar un poco de código la primera vez que se escribe.

Maven ha resuelto la reutilización del código. Soy completamente serio.

La reutilización de código es un tema extremadamente importante: cuando el código no se reutiliza, los proyectos tardan más y es más difícil para los nuevos miembros del equipo entrar.
Sin embargo, escribir código reutilizable lleva más tiempo.

Personalmente, intento escribir todo mi código de forma reutilizable, esto lleva más tiempo, pero resulta en el hecho de que la mayor parte de mi código se ha convertido en infraestructura oficial en mi organización y que los nuevos proyectos basados en estas infraestructuras toman mucho menos tiempo.

El peligro de reutilizar el código es si el código reutilizado no está escrito como una infraestructura, de manera general y encapsulada, con el menor número posible de suposiciones y la mayor cantidad posible de documentación y pruebas de unidades, que el código puede terminar haciendo cosas inesperadas.
Además, si se encuentran errores y se reparan, o se agregan características, estos cambios rara vez se devuelven al código fuente, lo que da como resultado diferentes versiones del código reutilizado, que nadie conoce ni entiende.

La solucion es:
1. Diseñar y escribir el código teniendo en cuenta no solo un proyecto, sino también pensar en los requisitos futuros e intentar que el diseño sea lo suficientemente flexible como para cubrirlos con un mínimo cambio de código.
2. Para incluir el código dentro de las bibliotecas que se utilizarán como están y no se modifican dentro de los proyectos.
3. Permitir a los usuarios ver y modificar el código de la biblioteca dentro de su solución (no dentro de la solución del proyecto en uso).
4. Diseñar proyectos futuros basados en las infraestructuras existentes, realizando los cambios necesarios en las infraestructuras.
5. Cargar el mantenimiento de la infraestructura a todos los proyectos, manteniendo así la infraestructura financiada.

Mi opinión personal, basada en la práctica en mi compañía:

¿Usted o su empresa intentan reutilizar el código?

Obviamente, si tenemos otro código que ya se ajuste a nuestras necesidades, lo reutilizaremos. Sin embargo, no salimos de nuestro camino para usar clavijas cuadradas en agujeros redondos.

En caso afirmativo, ¿cómo y en qué nivel, es decir, api de bajo nivel, componentes o lógica comercial compartida? ¿Cómo usan usted o su empresa el código de reutilización?

En todos los niveles. Está escrito en nuestros estándares de codificación que los desarrolladores siempre deben asumir que su código será reutilizado, incluso si en realidad eso es muy poco probable. Vea abajo

Si su modelo OO es bueno, su API probablemente refleje el dominio de su negocio, por lo que las clases reutilizables probablemente equivalen a una lógica comercial reutilizable sin esfuerzo adicional.

Para la reutilización real, un punto clave es saber qué código ya está disponible. Resolvemos esto al tener todo documentado en una ubicación central. Solo necesitamos un poco de disciplina para garantizar que la documentación esté actualizada y pueda buscarse de manera significativa.

¿Funciona?

Sí, pero no debido a la potencial o real reutilización. En realidad, más allá de algunas bibliotecas básicas y componentes de UI, no hay una gran cantidad de reutilización.

En mi opinión personal, el valor real es hacer que el código sea reutilizable . Al hacerlo, además de una API con la esperanza de que sea más limpia, el código (a) estará documentado lo suficiente para que otro desarrollador lo use sin pescar el código fuente , y (b) también será reemplazable . Estos puntos son un gran beneficio para el mantenimiento continuo del software.

¿Usted o su empresa intentan reutilizar el código? En caso afirmativo, ¿cómo y en qué nivel, es decir, api de bajo nivel, componentes o lógica comercial compartida? ¿Cómo usan usted o su empresa el código de reutilización?

Solía trabajar en una base de código con la reutilización de código uber, pero era difícil de mantener porque el código reutilizado era inestable. Era propenso a los cambios de diseño y la desaprobación de manera que caía en cascada a todo lo que lo usaba. Antes de eso, trabajé en una base de código sin reutilización de código donde las personas mayores alentaban realmente a copiar y pegar como una forma de reutilizar incluso el código específico de la aplicación, así que pude ver las dos extremidades y tengo que decir que una no es necesariamente mucho mejor que el otro cuando se lleva a los extremos.

Y solía ser un tipo de programador de abajo hacia arriba. Me pides que construya algo específico y termino construyendo herramientas generalizadas. Luego, usando esas herramientas, construyo herramientas generalizadas más complejas, luego empiezo a construir abstracciones DIP para expresar los requisitos de diseño para las herramientas de nivel inferior, luego construyo herramientas aún más complejas y las repito, y en algún momento empiezo a escribir código que realmente funciona. qué quieres que haga. Y a pesar de lo contraproducente que sonó, fui bastante rápido y pude enviar productos complejos de maneras que realmente sorprendieron a la gente.

¡El problema fue el mantenimiento durante meses, años! Después de que construí capas y capas de estas bibliotecas generalizadas y las volví a usar al máximo, cada una quería servir a un propósito mucho mayor que el que me pediste que hiciera. Cada capa quería resolver las necesidades de hambre del mundo. Entonces, cada uno era muy ambicioso: una biblioteca matemática que quiere ser increíble y resolver las necesidades de hambre del mundo. Luego, algo construido sobre la biblioteca matemática como una biblioteca de geometría que quiere ser increíble y resolver las necesidades de hambre del mundo. Sabes que algo anda mal cuando intentas enviar un producto, pero tu mente reflexiona sobre qué tan bien funciona tu biblioteca de geometría súper generalizada para renderizar y modelar cuando se supone que debes trabajar en animación porque el código de animación que estás trabajando on necesita algunas nuevas funciones de geometría.

Equilibrar las necesidades de todos

Encontré en el diseño de estas bibliotecas súper generalizadas que tenía que obsesionarme con las necesidades de cada miembro del equipo, y tuve que aprender cómo funcionaba el trazado de rayos, cómo funcionaba la dinámica de fluidos, cómo funcionaba el motor de malla, cómo funcionaba la cinemática inversa, cómo la animación de personajes funcionó, etc. etc. Tuve que aprender cómo hacer el trabajo de casi todo el mundo en el equipo porque estaba equilibrando todas sus necesidades específicas en el diseño de estas bibliotecas uber generalizadas que dejé atrás mientras caminaba sobre un equilibrista. del diseño se compromete con la reutilización de todos los códigos (tratando de mejorar las cosas para Bob trabajando en raytracing que está usando una de las bibliotecas pero sin lastimar mucho a John que está trabajando en física que también lo está usando pero sin complicar el diseño de la biblioteca) demasiado para hacer que ambos estén felices).

Llegué a un punto en el que estaba tratando de parametrizar cuadros delimitadores con clases de políticas para que se pudieran almacenar como centro y de la mitad del tamaño que una persona quería o extensiones mín. / Máx. Como alguien más quería, y la implementación se estaba complicando realmente tratando rápidamente de mantenerse al día con las necesidades de todos.

Diseño por comité

Y debido a que cada capa estaba tratando de satisfacer una amplia gama de necesidades (mucho más amplia de lo que realmente necesitábamos), encontraron muchas razones para requerir cambios de diseño, a veces por diseños solicitados por el comité (que generalmente son algo burdos). Y luego, esos cambios de diseño aparecerían en cascada hacia arriba y afectarían a todo el código de nivel superior al usarlo, y el mantenimiento de dicho código comenzó a convertirse en un PITA real.

Creo que potencialmente puedes compartir más código en un equipo de ideas afines. La nuestra no tenía la misma mentalidad. Estos no son nombres reales, pero tendría a Bill aquí, que es un programador y programador de GUI de alto nivel que crea buenos diseños para el usuario final pero un código cuestionable con muchos hacks, pero tiende a estar bien para ese tipo de código. Aquí tengo a Bob que es un viejo temporizador que ha estado programando desde la época de la tarjeta perforada, a quien le gusta escribir 10.000 funciones de línea con "gotos" en ellas y aún no entiende el tema de la programación orientada a objetos. Aquí tengo a Joe que es como un asistente matemático pero escribe código que nadie más puede entender y siempre hace sugerencias que están matemáticamente alineadas, pero no necesariamente tan eficiente desde un punto de vista computacional. Luego, conseguí que Mike, que está en el espacio ultraterrestre, quiera que conectemos el software a iPhones y cree que todos deberíamos seguir las normas y estándares de ingeniería de Apple.

Tratar de satisfacer las necesidades de todos aquí mientras creamos un diseño decente fue, probablemente en retrospectiva, imposible. Y en todos los que intentan compartir el código de cada uno, creo que nos volvimos contraproducentes. Cada persona era competente en un área, pero tratar de crear diseños y estándares con los que todos estén contentos acaba llevando a todo tipo de inestabilidad y ralentizó a todos.

Intercambios

Así que en estos días he encontrado que el equilibrio es para evitar la reutilización de código para las cosas de nivel más bajo. Utilizo un enfoque de arriba hacia abajo desde el nivel medio, tal vez (algo no demasiado alejado de lo que me pediste que haga), y construí allí una biblioteca independiente que todavía puedo hacer en un corto período de tiempo, pero la biblioteca no tiene la intención de producir mini-libs que intenten resolver las necesidades de hambre del mundo. Por lo general, estas bibliotecas tienen un propósito un poco más estrecho que las de nivel inferior (por ejemplo, una biblioteca de física en lugar de una biblioteca de intersección de geometría generalizada).

YMMV, pero si hay algo que he aprendido a lo largo de los años de la manera más difícil posible, es que podría haber un acto de equilibrio y un punto en el que podríamos evitar deliberadamente la reutilización del código en un entorno de equipo en un nivel granular, abandonando generalidad para el código de nivel más bajo a favor del desacoplamiento, tener código maleable, podemos conformarnos mejor para atender necesidades más específicas en lugar de generalizadas, etc., tal vez incluso dejando que cada uno tenga un poco más de libertad para hacer las cosas a su manera. Pero, por supuesto, todo esto es con el objetivo de seguir produciendo una biblioteca generalizada muy reutilizable, pero la diferencia es que la biblioteca podría no descomponerse en las bibliotecas generalizadas más pequeñas, porque descubrí que cruzar un cierto umbral e intentar crear demasiadas las bibliotecas pequeñas y generalizadas comienzan a convertirse en un esfuerzo extremadamente contraproducente a largo plazo, no en el corto plazo, sino a largo plazo y en un amplio esquema de cosas.

Si tiene un fragmento de código que podría compartirse potencialmente en una organización de tamaño mediano, ¿cómo informaría a otros miembros de la empresa que este lib / api / etc. existía y podría ser beneficioso?

Actualmente soy más reacio y encuentro más perdonable si los colegas hacen un trabajo redundante porque me gustaría asegurarme de que el código hace algo bastante útil y no trivial, y también está bien probado y diseñado antes de intentar compartirlo. con las personas y acumular un montón de dependencias. El diseño debe tener muy pocas razones para requerir cambios a partir de ese momento si lo comparto con el resto del equipo.

De lo contrario, podría causar más dolor de lo que realmente ahorra.

Solía ser tan intolerante con la redundancia (en el código o en los esfuerzos) porque parecía traducirse en un producto que era muy defectuoso y explosivo en el uso de la memoria. Pero me enfoqué demasiado en la redundancia como el problema clave, cuando realmente el problema real era la mala calidad, el código escrito apresuradamente y la falta de pruebas sólidas. El código bien probado, confiable y eficiente no sufriría ese problema casi en gran medida, incluso si algunas personas duplican, digamos, algunas funciones matemáticas aquí y allá.

Una de las cosas de sentido común que debo tener en cuenta y recordar que no tenía en ese momento es que no nos importa la redundancia cuando utilizamos una biblioteca de terceros muy sólida. Lo más probable es que usen una biblioteca de terceros o dos que tengan un trabajo redundante con lo que su equipo está haciendo. Pero no nos importa en esos casos porque la biblioteca de terceros es excelente y está bien probada. Recomiendo aplicar esa misma forma de pensar a su propio código interno. El objetivo debe ser crear algo asombroso y bien probado, no preocuparse por un poco de redundancia aquí y allá como erróneamente lo hice hace mucho tiempo.

Entonces, en estos días, cambié mi intolerancia hacia la falta de pruebas. En lugar de enojarme por los esfuerzos redundantes, ¡me resulta mucho más productivo molestarme por la falta de unidad y las pruebas de integración de otras personas! :-RE