Hemos renunciado a la idea de la reutilización de código?

Question

Hace un par de años los medios de comunicación estaba plagado de todo tipo de artículos en cómo la idea de la reutilización de código era una manera sencilla de mejorar la productividad y la calidad del código.

De los blogs y sitios que compruebe de forma regular parece como si la idea de "la reutilización de código" ha pasado de moda.Tal vez el " código de la reutilización de los defensores de tener todos se unieron a la SOA multitud lugar?:-)

Curiosamente, cuando se busca "la reutilización de código" en el Google el segundo resultado se titula:

"Interior De La Reutilización De Código Se Considera Peligroso"!

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

Lo que quiero saber es:

• ¿Usted o su empresa tratar y reutilizar el código?
• Si es así, cómo y a qué nivel, es decir,bajo nivel de api, componentes o comparte la lógica de negocio?¿Cómo usted o su empresa reutilización de código?
• Funciona?

Discutir?

---

Soy plenamente consciente de que hay muchos de código abierto libs disponibles y que cualquier persona que haya utilizado .NET o Java, ha reutilizado el código en alguna forma.Que es de sentido común!

Me refería más a la reutilización de código dentro de una organización, en lugar de a través de una comunidad a través de un lib compartido etc.

Me pidió originalmente;

• ¿Usted o su empresa tratar y reutilizar el código?
• Si es así, cómo y a qué nivel, es decir,bajo nivel de api, componentes o compartida de la lógica de negocio?¿Cómo usted o su empresa reutilización de código?

Desde donde estoy veo muy pocas ejemplo de las compañías tratando de reutilizar el código internamente?

Si usted tiene un pedazo de código que podría ser compartidos a través de un medio tamaño de la organización ¿cómo lo harías informar a otros miembros de la empresa que este lib/api/etc existía y que podrían ser de beneficio?

Answer 1

El título del artículo se está refiriendo es engañosa, y es en realidad una muy buena lectura. La reutilización de código es muy beneficioso, pero hay inconvenientes con todo. Básicamente, si no recuerdo mal, la esencia del artículo es que se está sellando el código en un cuadro negro y no volver a ellos, de manera que los desarrolladores originales se van a perder el conocimiento. Mientras veo el punto, no necesariamente de acuerdo con ella -. Al menos no en un sentido "el cielo se está cayendo"

En realidad grupo de reutilización de código en más de clases reutilizables simplemente, nos fijamos en toda la empresa. Las cosas que son más como marco de mejora o dirección conceptos transversales se ponen en un marco de desarrollo que todas nuestras aplicaciones de uso (piensan cosas como pre- y post-validación, registro, etc.). También tenemos la lógica de negocio que es aplicable a más de una aplicación, por lo que ese tipo de cosas son movidos a un núcleo de BAL que se puede acceder en cualquier lugar.

Creo que lo importante no es el de promover cosas para su reutilización, si no van a volver a utilizar realmente. Deben estar bien documentado, por lo que los nuevos desarrolladores pueden tener un recurso para ayudarles a llegar a la velocidad, también. Es probable que, si el conocimiento no se comparte, el código con el tiempo se reinventaron en otro lugar y dará lugar a la duplicación si no son rigurosos en la documentación y el intercambio de conocimientos.

Answer 2

Podemos reutilizar el código - de hecho, nuestros desarrolladores específicamente la escritura de código que pueden ser reutilizados en otros proyectos.Esto ha pagado muy bien - somos capaces de iniciar nuevos proyectos de forma rápida, y nosotros, de manera iterativa, endurecer nuestro núcleo de las bibliotecas.

Pero no se puede escribir el código y esperar a ser re-utilizado; la reutilización de código requiere la comunicación entre los miembros del equipo y otros usuarios para que las personas sepan qué código está disponible, y cómo usarlo.

Las siguientes cosas son necesarias para la reutilización de código para trabajar con eficacia:

• El código o en la propia biblioteca
• La demanda para el código a través de varios proyectos o esfuerzos
• La comunicación del código características/capacidades
• Instrucciones sobre cómo usar el código
• Un compromiso de mantener y mejorar el código a lo largo del tiempo

Answer 3

La reutilización de código es esencial. Me parece que también me obliga a generalizar lo más posible, también hacer el código más adaptable a diferentes situaciones. Lo ideal es que casi todas las bibliotecas de nivel inferior se escribe debe ser capaz de adaptarse a un nuevo conjunto de requisitos para una aplicación diferente.

Answer 4

Creo que la reutilización de código que se está haciendo a través de proyectos de código abierto en su mayor parte. Cualquier cosa que pueda ser reutilizado o extendido que se está haciendo a través de las bibliotecas. Java tiene un increíble número de librerías de código abierto disponibles para hacer un gran número de cosas. Compare esto con C ++, y cómo desde el principio todo lo que tendría que ser implementado desde cero utilizando MFC o la API de Win32.

Answer 5

La reutilización de código.

A pequeña escala que tratamos de evitar la duplicación de código tanto como sea posible. Y tenemos una biblioteca completa con una gran cantidad de código que se usa con frecuencia.

Código Normalmente se desarrolla para una sola aplicación. Y si es lo suficientemente genérica, es promovido a la biblioteca. Esto funciona excelente.

Answer 6

La idea de la reutilización de código ya no es una idea novedosa ... de ahí la aparente falta de interés. Pero sigue siendo en gran medida una buena idea. todo el marco .NET y la API de Java son buenos ejemplos de reutilización de código en acción.

Nos hemos acostumbrado al desarrollo de las bibliotecas de código OO para nuestros proyectos y reutilizarlos en otros proyectos. Es una parte del ciclo de vida natural de una idea. Se discute caliente durante un tiempo y luego todo el mundo acepta y no hay ninguna razón para continuar el debate.

Answer 7

Por supuesto que la reutilización de código.

Hay una casi infinita cantidad de paquetes, bibliotecas y objetos compartidos está disponible para todos los idiomas, con las comunidades enteras de desarrolladores detras de ellos apoyo y actualización.

Answer 8

Creo que la falta de "atención de los medios" se debe al hecho de que todo el mundo lo está haciendo, por lo que ya no es vale la pena escribir. No escucho a tanta gente sensibilización de la programación orientada a objetos y pruebas unitarias como antes tampoco. Todo el mundo ya es consciente de estos conceptos (si o no utilizar).

Answer 9

El nivel de atención de los medios a un problema tiene poco que ver con su importancia, si estamos hablando de desarrollo de software o la política! Es importante evitar el desperdicio de esfuerzo de desarrollo reinventando (o volver a mantener!) De la rueda, pero esto es tan conocida por ahora que un editor probablemente no va a conseguir excitado por otro artículo sobre el tema.

En lugar de mirar el número de artículos actuales y blogs como una medida de la importancia (o urgencia) mirar los conceptos y zumbido frases que se han convertido en clásicos o entrado en la jerga (otra forma de reutilización!) Por ejemplo, google para los usos de la sigla DRY para una buena discusión sobre las muchas formas de redundancia que puede ser eliminado en los procesos de software y de desarrollo.

También hay un papel para la madurez de juicio respecto a los costos de reutilización frente a donde se consiguen los beneficios. Algunos autores abogan por la espera que preocuparse de reutilización hasta que un segundo o tercer uso emerge en realidad, en lugar de gastar esfuerzo para generalizar poco de código la primera vez que se escribe.

Answer 10

Mi punto de vista personal, basada en la práctica en mi empresa:

  

  
• ¿Usted o su empresa tratar y reutilizar el código?
  

Obviamente, si tenemos otra pieza de código que ya se ajusta a nuestras necesidades vamos a volver a utilizarlo. No salir de nuestra manera de utilizar clavijas cuadradas en agujeros redondos sin embargo.

  

  
• Si tan cómo y en qué nivel, es decir, de bajo nivel de API, componentes o lógica de negocio compartido? ¿Cómo hacer usted o su código de la compañía reutilización?
  

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

Si el modelo OO es buena, su API probablemente refleja su dominio del negocio, por lo que las clases reutilizables probablemente equivale a la lógica de negocio reutilizable y sin esfuerzo adicional.

Para la reutilización real, un punto clave es saber lo que ya está disponible el código. Resolvemos esto por tener todo documentado en una ubicación central. Sólo necesitamos un poco de disciplina para asegurar que la documentación está al día y se pueden buscar de una manera significativa.

  

  
• ¿Funciona?
  

Sí, pero no debido a la reutilización potencial o real! En realidad, más allá de unas pocas bibliotecas del núcleo y componentes de interfaz de usuario, no hay una gran cantidad de reutilización.

En mi opinión personal, el valor real está en hacer que el código reutilizable . De este modo, aparte de una API de esperar más limpio, el código será documentada (a) lo suficiente para que otro desarrollador para usarlo sin arrastre el código fuente , y (b) también será reemplazable . Estos puntos son un gran beneficio para el mantenimiento continuo de software.

Answer 11

Aunque creo que la reutilización de código es valioso, puedo ver donde está arraigado este sentimiento. He trabajado en muchos proyectos en que se tomó mucho cuidado para crear reutilizable código que fue luego no volver a utilizar. Por supuesto, la reutilización es mucho más preferible duplicar todo el código, pero he visto una gran cantidad de modelos de objetos muy extenisve creados con el objetivo de utilizar los objetos a través de la empresa en varios proyectos (tipo de la forma en que el mismo servicio en SOA se puede utilizar en diferentes aplicaciones) pero nunca han visto los objetos realmente utilizados más de una vez. Tal vez simplemente no han sido parte de las organizaciones que tienen buena ventaja del principio de reutilización.

Answer 12

Los dos proyectos de software que he trabajado tienen tanto el desarrollo estado a largo plazo. Uno de ellos es de unos 10 años de edad, el otro ha sido de alrededor de más de 30 años, reescrito en un par de versiones de Fortran lo largo del camino. Ambos hacen extensa reutilización de código, pero ambos dependen muy poco de herramientas externas o librerías de código. DRY es un gran mantra en el proyecto más reciente, que se encuentra en C ++ y se presta más fácilmente a hacer eso en la práctica.

Answer 13

Tal vez la mejor pregunta es cuando NO tenemos la reutilización de código en estos días?Estamos en un estado en edificio con alguien más observado de las "mejores prácticas" o prediscovered "patrones de diseño" o simplemente de construir en el código de la herencia, las bibliotecas, o la copia.

Parece que el grado en el que Un código se reutilizan para hacer que el código B se basa a menudo en torno a cuánto las ideas en código de Una toma para el código de B se abstrae en patrones de diseño/modismos/libros/fugaces pensamientos/real/código de las bibliotecas.La parte difícil es en la aplicación de todas esas buenas ideas para el código real.

No técnicos tipos de llegar exceso de celo sobre la reutilización cosa.No entiendo por qué todo no puede ser la copia-pega.Ellos no entienden por qué el greemelfarm necesita un adaptador especial para comunicar la misma información que se utiliza para el viejo sistema al nuevo sistema, y que, por desgracia, no puede cambiar, ya sea debido a un bazillion otras razones.

Creo que los técnicos han sido reutilización desde el día 1 en la misma forma en que los músicos han sido reutilización desde el día 1.Se trata de un curso de la evolución orgánica y sythesis que se mantenga en curso.

Answer 14

La reutilización de código es una cuestión extremadamente importante - en el que el código no es reutilizado, proyectos toman más tiempo y son más difíciles para los nuevos miembros del equipo para conseguir en.
Sin embargo, la escritura de código reutilizable que lleva más tiempo.

Personalmente, trato de escribir todo mi código de forma reutilizable, esto toma más tiempo, sino que se traduce en el hecho de que la mayor parte de mi código se ha convertido en oficial de las infraestructuras en mi organización, y que los nuevos proyectos basados en estas infraestructuras tomar mucho menos tiempo.

El peligro en la reutilización de código, es si el reutilizar código que no está escrito como una infraestructura en general y encapsulado manera con el menor número posible de supuestos y tanto como sea posible de la documentación y de la unidad de pruebas, que el código puede terminar haciendo cosas inesperadas.
También, si los insectos se encuentran y fija, o funciones que se han añadido, estos cambios son rara vez devuelto el código fuente, lo que resulta en diferentes versiones de los reutilizar código, que nadie sabe o entiende.

La solución es:
1.Diseñar y escribir el código con no sólo un proyecto en mente, pero pensar en el futuro de los requisitos y tratar de hacer el diseño lo suficientemente flexible como para cubrir con un mínimo de cambio de código.
2.Para encerrar el código dentro de las bibliotecas que se han de utilizar como es y no se modifica en el uso de los proyectos.
3.Para permitir a los usuarios ver y modificar el código de la biblioteca dentro de su solución (no dentro del proyecto de la solución).
4.El diseño de futuros proyectos basados en las infraestructuras existentes, la realización de cambios a la infraestructura necesaria.
5.A cargo del mantenimiento de la infraestructura para todos los proyectos, por lo que mantiene la infraestructura financiados.

Answer 15

  

¿Tiene usted o su empresa intenta y reutilizar el código? Si es así cómo y en qué   nivel, es decir, la API de bajo nivel, componentes o lógica de negocio compartido? Como hacer   usted o su código de la compañía reutilización?

Yo 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 desaprobación de manera que en cascada a todo lo usarlo. Antes de que yo trabajaba en una base de código sin la reutilización de código, donde las personas mayores en realidad anima a copiar y pegar como una forma de reutilizar el código, incluso para aplicaciones específicas, por lo que tiene que ver las dos extremidades y tengo que decir que uno no es necesariamente mucho mejor que el otro cuando se toma a los extremos.

Y yo solía ser una especie de abajo hacia arriba uber del programador. Me preguntas para construir algo específico y termino la construcción de herramientas generalizadas. Luego, utilizando esas herramientas, construyo herramientas generalizadas más complejas, a continuación, empezar a construir abstracciones DIP para expresar los requisitos de diseño para las herramientas de nivel inferior, a continuación, voy a construir herramientas aún más complejas y repito, y en algún momento me pongo a escribir código que realmente hace qué quieres que haga. Y como contraproducente, ya que sonaba, yo era bastante rápido en ella y podría enviar los productos complejos de forma que la gente realmente sorprendido.

El problema era que el mantenimiento a lo largo de los meses, años! Después de construir capas y capas de estas bibliotecas generalizadas y volver a utilizar el infierno fuera de ellos, cada uno quería servir a un propósito mucho mayor que lo que me pide que haga. Cada capa quería resolver las necesidades de hambre en el mundo. Por lo que cada uno era muy ambicioso: una biblioteca de matemáticas que quiere ser increíble y resolver las necesidades de hambre en el mundo. Entonces algo construido en la parte superior de la biblioteca matemática como una biblioteca geometría que quiere ser increíble y resolver las necesidades de hambre en el mundo. Usted sabe que algo anda mal cuando se está tratando de enviar un producto, pero su mente está analizando más de lo bien que la biblioteca de geometría súper generalizada trabaja para la representación y modelado cuando se supone que está trabajando en la animación ya que el código de animación que está trabajando en las necesidades de algunas nuevas funciones de geometría.

Necesidades Equilibrio de todos los usuarios

I encontrado en el diseño de estas bibliotecas uber-generalizada que tuve que obsesionarse con las necesidades de cada miembro del equipo, y tuve que aprender cómo funcionaba el trazado de rayos, cómo funcionaban los fluidos dinámica, cómo funcionaba el motor de malla, la forma en la cinemática inversa trabajado, cómo funcionaba la animación de personajes, etc, etc, etc que tenía que aprender a hacer el trabajo más o menos de todos en el equipo porque estaba equilibrando la totalidad de sus necesidades específicas en el diseño de estas bibliotecas súper generalizada deje atrás mientras camina una cuerda floja acto de equilibrio de compromisos de diseño de toda la reutilización de código (tratando de hacer las cosas mejor para Bob trabajando en el trazado de rayos que está utilizando una de las bibliotecas, pero sin perjudicar a John exceso que está trabajando en la física que es también el uso de ella, pero sin complicar el diseño de la biblioteca demasiado para que sean a la vez feliz).

Se llegó a un punto en el que estaba tratando de parametrizar cajas con clases de política que limita de modo que pudieran ser almacenados ya sea como centro y la mitad de tamaño que una persona quiere o min / máximo de extensión como alguien más quería, y la puesta en práctica era consiguiendo contorneado muy rápido frenéticamente tratando de mantener al día con las necesidades de todos.

Diseño Por Comité

Y porque cada capa estaba tratando de servir a una gama tan amplia de necesidades (mucho más amplio de lo que realmente es necesario), se encontraron muchas razones para requerir cambios en el diseño, a veces por los diseños del comité-solicitado (que suelen ser algo desagradable). Y a continuación, los cambios de diseño serían en cascada hacia arriba y afectará a todo el código de nivel superior a usarlo, y el mantenimiento de dicho código comenzado a convertirse en un verdadero PITA.

Creo que se puede compartir potencialmente más código en un equipo de ideas afines. La nuestra no era propio de menteen absoluto. Estos no son nombres reales, pero me gustaría tener a Bill, que es un programador de interfaz gráfica de usuario de alto nivel y guionista que crea diseños de fin de usuario agradable pero el código cuestionable con una gran cantidad de hacks, pero tiende a estar bien para ese tipo de código. Tengo Bob aquí que es un viejo contador de tiempo que ha estado programando desde la época de tarjetas perforadas que le gusta escribir 10.000 funciones de línea con GOTOS en ellos y todavía no conseguir el punto de la programación orientada a objetos. Tengo Joe aquí que es como un asistente matemático, sino que escribe el código que nadie más puede entender y siempre hacer sugerencias que son matemáticamente bien alineados, pero no necesariamente de manera eficiente desde un punto de vista computacional. Entonces tuve Mike aquí que está en el espacio exterior que nos quiere trasladar el software de iPhones y piensa que todos deberíamos seguir las convenciones de Apple y estándares de ingeniería.

Tratando de satisfacer las necesidades de todos aquí mientras viene con un diseño decente era, probablemente, en retrospectiva, imposible. Y en todo el mundo tratando de compartir el código del uno al otro, creo que se convirtió en contraproducente. Cada persona era competente en un área, pero tratando de llegar a los diseños y normas que todos están contentos con simplemente dar lugar a todo tipo de inestabilidad y se redujo a todo el mundo.

compensaciones

Así que estos días he encontrado el equilibrio es evitar la reutilización de código para las cosas de nivel más bajo. Yo uso un enfoque de arriba hacia abajo desde el nivel medio, tal vez (algo que no es también ahora divorciada de lo que me pide que haga), y construir alguna biblioteca independiente allí, que todavía puedo hacer en un corto cantidad de tiempo, pero la biblioteca no tiene intención de producir mini-libs que tratan de resolver las necesidades de hambre en el mundo. Por lo general, estas bibliotecas son un poco más estrecha en el propósito que los de nivel inferior (por ejemplo: una biblioteca física en contraposición a una biblioteca geometría de la intersección generalizada).

Tu caso es distinto, pero si hay algo que he aprendido a lo largo de los años en las formas más duras posibles, es que puede haber un acto de equilibrio y un punto en el que lo que se quiere evitar deliberadamente la reutilización de código en un ambiente de equipo en algún nivel granular , abandonando cierta generalidad para el código de nivel más bajo en favor de desacoplamiento, que tiene código maleable que puede mejorar la forma de atender a más específico en lugar de necesidades generalizadas, y así sucesivamente - tal vez incluso sólo dejar que cada uno tiene un poco más de libertad para hacer las cosas a su Propia manera. Pero, por supuesto, todo esto es con el objetivo de seguir produciendo una biblioteca muy reutilizable, generalizado, pero la diferencia es que la biblioteca podría no descomponerse en las bibliotecas generalizadas teeniest, porque he encontrado que cruzar un umbral determinado y tratando de hacer demasiadas pequeñito, bibliotecas generalizadas empieza a ser realmente un esfuerzo extremadamente contraproducente en el largo plazo - no en el corto plazo, pero en el largo plazo y amplio esquema de las cosas

.

  

Si usted tiene una pieza de código que potencialmente podría ser compartido a través de una   organización de tamaño mediano cómo haría usted para informar a otra   miembros de la empresa que este lib / api / etc existido y podría ser de   beneficiar?

De hecho, me siento más reticentes en estos días y parece que es más perdonable si los colegas hacen un trabajo redundante porque me gustaría que para asegurarse de que el código hace algo bastante útil y no trivial y está también muy bien probado y diseñado antes de tratar compartirla con la gente y acumular un montón de dependencias a él. El diseño debe tener muy, muy pocas razones para requerir ningún cambio desde ese punto en adelante si lo comparto con el resto del equipo.

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

Yo solía ser tan intolerante de la redundancia (en clave o esfuerzos) porque parecía traducirse en un producto que era muy buggy y explosivo en el uso de memoria. Pero me acercaste demasiado en la redundancia como el principal problema, cuando en realidad el problema real era de mala calidad, el código escrito apresuradamente, y unfalta de pruebas sólido. probado bien, el código fiable, eficiente no sufriría ese problema a casi tan grande de un grado incluso si algunas personas se duplican, por ejemplo, algunas funciones matemáticas aquí y allá.

Una de las cosas de sentido común a la vista y recordar que no lo hice en el momento es cómo no nos importa algo de redundancia cuando utilizamos una biblioteca de terceros muy sólido. Lo más probable es que ustedes utilizar una biblioteca de terceros o dos que tiene un trabajo redundante con lo que su equipo está haciendo. Pero no nos importa en estos casos debido a que la biblioteca de terceros es grande y bien probado. Recomiendo la aplicación de ese mismo modo de pensar a su propio código interno. El objetivo debe ser crear algo impresionante y bien probado, no alboroto sobre un poco de redundancia aquí y allí, ya que por error hice hace mucho tiempo.

Así que estos días hemos cambiado mi intolerancia hacia la falta de pruebas en su lugar. En lugar de obtener molesto por los esfuerzos redundantes, me resulta mucho más productivo para conseguir molesto por la falta de unidad y pruebas de integración de otras personas! -D

Answer 16

Maven ha resuelto la reutilización de código. Estoy completamente en serio.