¿Cómo creo y mantengo una biblioteca de reutilización de código?

Question

Estoy intentando configurar un repositorio de código reutilizable.Estaba pensando en que cada módulo de código reutilizable tuviera una determinada calificación de "Nivel de madurez".La calificación se definiría como el nivel en el que un código reutilizable se encuentra dentro de un determinado conjunto de requisitos.El nivel de madurez más alto será el grado más alto de estándar en un conjunto predefinido de requisitos.

Por ejemplo:
Nivel;Requisitos;Descripción
Nivel 0;El uso del código es legal;¿Es legal el uso del código en la industria comercial/en múltiples contratos/etc.?
Nivel 1;Línea de código base y cumple con los requisitos de nivel 0;Código prototipado, herramientas de terceros, etc.
Nivel 2;Tiene interfaz de funciones y comentarios y cumple con los requisitos de nivel 1;Documentación suficiente para cada clase y función;Capaz de determinar la funcionalidad a partir de comentarios.
Nivel 3;Cumple con los estándares de codificación y cumple con los requisitos de nivel 2;Sigue estándares de codificación definidos y pasa la prueba de utilidad de verificación de código
Nivel 4;Incluye casos de prueba y cumple con los requisitos de nivel 3;Tiene suficientes casos de prueba para probar todas las funciones del código.
Nivel 5;Aprobado por el comité de reutilización y cumple con los requisitos de nivel 4;Revisado por expertos y pares en reutilización y verificado que cumple con todos los niveles de madurez.

Me pregunto si este nivel de madurez debería ser una estructura jerárquica, donde para pasar al siguiente nivel es necesario cumplir con los requisitos de todos los niveles anteriores (como he mostrado arriba).

¿O si debería ser un subconjunto de requisitos para alcanzar el siguiente nivel?

Por ejemplo, si cumplimos con x de y requisitos, podemos pasar al siguiente nivel (los requisitos serían los mismos que se mencionaron anteriormente).

Nivel 0, cumple 0 de 6 requisitos
Nivel 1, cumple 1 de 6 requisitos
…

El problema que veo con el enfoque de subconjunto es que algunos requisitos deberían tener una ponderación más fuerte, y en este enfoque eso no se tendrá en cuenta (a menos que empiece a ser específico, cumpla con a de b y x de y, etc.).Pero entonces podría empezar a complicarse.

¿Alguien ha hecho esto antes? Si es así, ¿cómo configuró su biblioteca?¿Tiene algún nivel de madurez o alguna otra estructura?Cualquier contribución será muy apreciada.

Answer 1

La creación de un repositorio de reutilización de código es una tarea difícil. La principal dificultad no está en la forma en que lo creó, pero en cómo se comunica la existencia de las diferentes bibliotecas en el repositorio. bibliotecas de reutilización sólo es bueno si se utilizan, y se utilizan sólo si se conocen, y que sólo se utilizan ampliamente si la calidad del código es alto y si se ajusta a las necesidades de los usuarios.

Me gusta la idea de los niveles de madurez, pero, como otros han dicho, es probable que haya un poco de configuración / construcción trabajo que hacer. He pensado en un enfoque similar al construye de una aplicación - Los llamé niveles de confianza. En el ámbito de aplicación a la generación, acumulación mínima confianza es uno que no pasaron las pruebas de unidad; una confianza media podría incluir pruebas que pasan unidad, pero no las pruebas de integración, y así sucesivamente. Este fue un buen mecanismo para comunicar a los usuarios control de calidad y qué esperar. Un mecanismo similar puede ser apropiado para las bibliotecas.

Los comentarios de documentación son una necesidad, y también deben tener el mismo cuidado puesto en ellos y cuando se pone en el código. Los comentarios deben comunicar qué, por qué, dónde, cuándo, cómo, que, etc Su proceso de construcción debe publicar la documentación en una ubicación conocida (una vez más, la comunicación es clave).

A lo largo de las líneas de comunicación, que no hace daño a presentar de vez en cuando simplemente lo que hay. ¡De nuevo! comunicación.

Así que, como mínimo su construcción de cada biblioteca debe:

• publicar la biblioteca (tal vez notificar a los suscriptores)
• publicar la documentación
• pruebas de unidad de ejecución
• publicar el nivel de madurez

En cuanto a los niveles de madurez, yo definiría con un "nombre de nivel" y una descripción de lo que significa el nivel. Publicar los criterios de lo que significa moverse hacia arriba o hacia abajo un nivel. En realidad, ahora que lo pienso, quizás usted quiere un conjunto de criterios ortogonales: un nivel para el código, un nivel para la documentación, uso-políticas (es decir, debe tener una licencia para XYZ), y otros atributos. Yo recomiendo que se acerque esto en pequeños incrementos sin embargo. Al final del día, la entrega de funcionalidad a los usuarios finales es lo que importa.

Hay que comunicar también una mentalidad de empujar de forma natural los bits reutilizables en el repositorio. Los desarrolladores tienen que tener incentivos para hacer esto por lo general. Código de comprobación herramientas estáticas que buscar duplicación y la evaluación por pares sólo llegan hasta allí. Alguien tiene que hacer realidad el trabajo de mover código al repositorio.

Por último, recomiendo que utilice el mayor apoyo posible herramienta en la configuración, construir, mantenimiento y comunicación del repositorio. De lo contrario, como cualquier artefacto no-código, que se enfrentará a una cierta cantidad de entropía que disminuye el valor que el artefacto no se convierte en código de fecha.

Answer 2

Creo que le resultará difícil asegurarse de que todo el equipo de desarrollo siga estas pautas con la suficiente precisión.Especialmente cuando las directrices pueden interpretarse de una forma u otra.Además, será una gran molestia si alguien mejora un fragmento de código agregando pruebas y de repente tiene que pasar a un proyecto diferente.Lo más probable es que dicho código permanezca en el proyecto en el que se colocó originalmente y, con el tiempo, los niveles de madurez dejarán de tener sentido.

Un enfoque que vi que funciona bien en una gran empresa es el siguiente:

• Todas las bibliotecas de terceros están asignadas a un directorio especial y siempre incluyen un número de versión.
• Nuestras propias bibliotecas comunes se dividen según la referencias tienen que hacer otras cosas.P.ej.si el código de utilidad hace referencia a Infragistics biblioteca entonces este fragmento de código de utilidad va a una InfragisticsUtils biblioteca.
• Nuestras propias bibliotecas comunes, que forman "unidades" claramente identificables, van a bibliotecas separadas.Por ejemplo, una biblioteca de código que se ocupa de la fijación de precios de valores es un proyecto independiente.
• Todo el código reutilizable que no cumpla con ninguno de los requisitos anteriores entra en un cajón de sastre. Utilities proyecto.
• Nuestras propias bibliotecas se compilan y publican en una ubicación compartida donde los proyectos pueden hacer referencia a ellas.Depende del equipo de desarrollo del proyecto decidir si quiere hacer referencia a un binario compilado o simplemente incluir el proyecto de utilidad en su solución.

Obviamente la calidad del código que encuentras en el cajón de sastre. Utilities La biblioteca puede variar significativamente.Para aliviar esto, simplemente nos aseguramos de que dos personas de diferentes equipos de desarrollo revisaran todos los registros para Utilities.¡Esto elimina muchas cosas que no tienen cabida allí!

Answer 3

Creo que un gran repositorio de código incluiría una herramienta de CM y una herramienta Wiki. La herramienta CM deberá estructurarse utilizando la idea de nivel (como usted propuso), ya que las estructuras del código de calidad. El wiki debe actuar como un "anuncio" de lo que el software puede hacer y cómo puede ayudarle. Este wiki también podría mantener la información como, qué proyectos están utilizando el código, la calificación de la forma en que es utilizable, y ejemplos de cómo usarlo. Si alguien está preocupado por el equipo de desarrollo siguiendo las directrices de nivel, hay que señalar cómo funciona la auto policial y dar el ejemplo de lo bien que funciona con los wikis.

Ahora, la estructuración de la herramienta CM es importante. Está diseñado para transmitir la calidad del código, para que sepa lo que se obtiene en cuando lo utiliza. Por ejemplo, si se escribe una clase simple sin apenas comentarios y que en realidad no sostienes a los estándares (tal vez un prototipo) que codifica entonces sería entró en \ sw_repository \ level0 \ ExamplePrototype.

Tal vez alguien se detiene trozo de código y los comentarios añadidos y lo lleva a la altura. Entonces esa persona sería colocarlo en \ sw_repository \ level1 \ ExamplePrototype.

A continuación, esa misma persona, un rato más tarde, crea las pruebas unitarias para el ExamplePrototype. Esto entonces ir al nivel 2 y así sucesivamente.

La definición de los niveles debería tomar algún pensamiento. Que en realidad debería ser algo secuencial e incluso si, por ejemplo, que había escrito las pruebas unitarias para el código de prototipo pero no cumplía los comentarios y estándar de codificación, entonces es colocado en level0 de todos modos. Sin embargo, sería fácil ir al nivel 2 si se cumplen dichos comentarios y normas.

Answer 4

Para mi biblioteca, acabo de poner en el código que he escrito que se puede utilizar en múltiples aplicaciones. Si el código es específico de una aplicación en particular, entonces no va a la biblioteca. A medida que más aplicaciones lo utilizan, los insectos se elaboran por lo que nunca esperaba que fuera libre de errores de inmediato. Insectos se encuentran en constante y se fijaron como su biblioteca madura y se destacó con diferentes aplicaciones. Nunca será libre de errores, pero con el tiempo se acercará a la fiabilidad. También cuando me di cuenta de que la API para algunas cosas está mal, no me preocupo por ella y refactorizar la API tan pronto como sea posible.

Aquí está mi biblioteca en C ++
http://code.google.com/p/kgui/

Answer 5

Durante años Microsoft ha sido un gran defensor de lo que se conoce como fábricas de software , una gran parte de los cuales está dedicado a resolver los problemas de reutilización.

¿Cuáles son los problemas de reutilización? En primer lugar, es difícil. Es muy difícil llegar a una biblioteca y API que servirá más allá de las necesidades inmediatas del proyecto en cuestión. ¿Cómo se puede predecir el futuro? Además, el problema de un repositorio centralizado que sirve como una base de conocimientos y una vibrante comunidad de práctica es muy difícil. ¿Cómo se hace algo que es a la vez muy flexible y fácil de usar? Muchos han intentado y fallado. Ambas fábricas de software y líneas de productos de software intento de abordar estos problemas.

Buena suerte!

Answer 6

Kit mencionado el problema más importante: la reutilización . el resto de la idea es buena, pero no es más que un detalle.

i decir, yo mismo tengo problemas para mantener mi propia biblioteca reutilización. A veces hago una implementación que es muy específica para el proyecto, o hago el prototipo de orden n de una idea, y ninguno de los que llega a ponerse en mi biblioteca.

si realmente tener éxito en tener una biblioteca de reutilización de código, que es usado y mantenido por muchos desarrolladores, de una manera disciplinada, que es la victoria. se necesita un sistema de control de versiones y un gestor de fallos, siendo este último utilizado por los propietarios y los usuarios del proyecto. que necesita la comunicación y los medios de aportación. tener un puñado de desarrolladores que utilizan un proyecto de mejora drásticamente su calidad. aplicación se pone mejor. Se crea la documentación. API y el diseño están en función de un nivel mucho más alto. un comité es una cosa agradable, pero no puede decidir, dado lo bien que es el código, sin tener que usarlo. puede decidir si el código cumple con las normas específicas, pero el cumplimiento de las normas no es suficiente para buenas bibliotecas.

que tiene que hacer todo lo posible para asegurarse de que, usted no tiene toneladas de fragmentos de código que flotan alrededor, todo lo cual puede más o menos hacer algo. ok, cualquier decisión de diseño tiene pros y contras, pero creo, que tiene más sentido para comenzar con un proyecto para una tarea determinada, y se ramifican, si es realmente necesario, pero mantener viva la comunicación entre los equipos de proyecto, y considerar (parcialmente) la fusión espalda.

no se preocupe demasiado acerca de la clasificación de la calidad de los diferentes proyectos. si un proyecto es malo, entonces los usuarios / desarrolladores a promover el tema a un mejor nivel. la mayoría de la gente es lo suficientemente inteligente como para ver, cuando una biblioteca es buena, y cuando no lo es. que realmente necesita para poner su energía en estos efectos simbióticas, en lugar de tratar a los participantes carga con reglas estrictas.

sólo mis 2 centavos ...;)

Answer 7

Mira Will Tracz de "Confesiones de un viajante programa utilizado", y otras cosas por el rabino reutilización de HP, Martin Griss.

Answer 8

Creo que usted está pensando demasiado en un no problema.

¿Cómo se hizo configuración de mi biblioteca? fácil, si se utiliza la misma (casi el mismo o) método en dos o más proyectos, se mueve hacia la biblioteca.

Answer 9

Se considera buena cuando se quiere disponer de la propia biblioteca, pero que mil líneas uno es una ruina!