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

Question

Estoy tratando de configurar un repositorio de código reutilizable. Estaba pensando en tener cada módulo de código reutilizable con una cierta calificación de "Nivel de madurez". La calificación se definiría como el nivel en el cual un código reutilizable se encuentra dentro de un cierto conjunto de requisitos. El nivel de madurez más alto será el grado más alto de estándar en un conjunto de requisitos predefinidos.

Por ejemplo:
Nivel; Requisitos; Descripción
Nivel 0; El código es legal de usar; ¿El código es legal para usar en la industria comercial/a través de contratos múltiples/etc.?
Nivel 1; Línea de código base y cumple con los requisitos de nivel 0; Código prototipo, 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 de los comentarios
Nivel 3; Se adhiere a los estándares de codificación y cumple con los requisitos de nivel 2; Sigue los 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 toda la funcionalidad del código
Nivel 5; Aprobado por el comité de reutilización y cumple con los requisitos del nivel 4; Revisado por expertos en reutilización y pares y verificado que cumple con todos los niveles de madurez

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

O si debe ser un subconjunto de requisitos para alcanzar el siguiente nivel?

Por ejemplo, hemos cumplido x de los requisitos, podemos pasar al siguiente nivel (los requisitos serían los mismos que los mencionados anteriormente).

Nivel 0, cumple 0 de 6 requisitos
Nivel 1, se reúne 1 de cada 6 requisitos
...

El problema que veo con el enfoque subconjunto es unos requisitos debe tener una ponderación más fuerte, y en este enfoque que no se tendrá en cuenta (a menos que empiece a ser específico como, cumple con un out de byx de y, etc.). Pero luego podría comenzar a complicarse.

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

Answer 1

Configurar un repositorio de reutilización de código es una tarea difícil. La principal dificultad no está en cómo configurarlo, sino en cómo se comunica la existencia de las diversas bibliotecas en el repositorio. Las bibliotecas de reutilización solo son buenas si se usan, y solo se usan si se conocen, y solo se usan ampliamente si la calidad del código es alta y si satisface las necesidades de los usuarios.

Me gusta la idea de los niveles de madurez, pero como otros han publicado, probablemente haya bastante trabajo de instalación/construcción. He pensado en un enfoque similar para las versiones de una aplicación, los llamé niveles de confianza. En el campo de construcción de aplicaciones, una construcción de baja confianza es aquella que no pasó las pruebas unitarias; una confianza media puede incluir pasar pruebas unitarias, pero no pruebas de integración, y así sucesivamente. Este fue un buen mecanismo para comunicar a QA y a los usuarios qué esperar. Un mecanismo similar podría ser apropiado para las bibliotecas.

Los comentarios de documentación son obligatorios, y también deben tener tanto cuidado como poner en el código. Los comentarios deben comunicar qué, por qué, dónde, cuándo, cómo, qué, etc.Su proceso de compilación debe publicar la documentación en una ubicación conocida (nuevamente, la comunicación es la clave).

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

Así que, como mínimo la compilación de cada biblioteca debe:

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

En cuanto a los niveles de madurez, los definiría con un "nombre de nivel" y una descripción de lo que el nivel significa. Publique los criterios de lo que significa subir o bajar un nivel. En realidad, ahora que lo pienso, tal vez desee un conjunto de criterios ortogonales: un nivel para el código, un nivel para la documentación, políticas de uso (es decir, debe tener una licencia para XYZ) y otros atributos. Sin embargo, te recomiendo que te acerques a esto en pequeños incrementos. Al final del día, entregar funcionalidad a los usuarios finales es lo que importa.

También tiene que comunicar una mentalidad de empujar naturalmente bits reutilizables en el repositorio. Los desarrolladores tienen que tener incentivos para hacer esto por lo general. Las herramientas de comprobación de códigos estáticos que buscan duplicación y revisiones por pares solo llegan tan lejos. Alguien tiene que hacer el trabajo de mover el código al repositorio.

Finalmente, le recomiendo que use la mayor cantidad de soporte de herramientas posible en la configuración, construcción, mantenimiento y comunicación del repositorio. De lo contrario, como cualquier artefacto sin código, se encontrará con una cierta cantidad de entropía que disminuirá el valor a medida que el artefacto sin código se vuelva anticuado.

Answer 2

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

¿Cómo configuró mi biblioteca? Fácil, si usa el mismo (o casi el mismo) método en dos o más proyectos, muévalo a la biblioteca.

Answer 3

Para mi biblioteca, puse el código que escribí que se puede usar en múltiples aplicaciones. Si el código es específico de una aplicación en particular, entonces no entra en la biblioteca. A medida que más aplicaciones lo usan, los errores se solucionan, por lo que nunca espero que estén libres de errores de inmediato. Los errores se encontrarán y arreglarán constantemente a medida que la biblioteca madure y se destaque con diferentes aplicaciones. Nunca estará libre de errores, pero con el tiempo se acercará a la fiabilidad. Además, cuando me doy cuenta de que la API para algunas cosas está mal, no me preocupo y refactorizar la API lo antes posible.

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

Answer 4

Creo que va a tener dificultades para asegurar que todo el equipo de desarrollo sigue estas directrices con suficiente precisión. Especialmente cuando las pautas se pueden interpretar de una forma u otra. Además, será un gran dolor si alguien mejora una pieza 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 perderán sentido.

Un enfoque vi trabajando bien en una gran empresa es la siguiente:

• Todas las bibliotecas de terceras partes se comprometen a un directorio especial y siempre incluyen un número de versión.
• Nuestras propias bibliotecas comunes se dividen en base a las referencias que tienen a otras cosas. P.ej. si el código de la utilidad hace referencia a la biblioteca Infragistics, este pequeño código de utilidad va a una biblioteca InfragisticsUtils.
• Nuestras propias bibliotecas comunes que forman "unidades" claramente identificables van a bibliotecas separadas. Por ejemplo, una biblioteca de código que se ocupa de valores de fijación de precios es un proyecto separado.
• Todo el código reutilizable que no satisface ninguno de los anteriores va a un proyecto Utilities catch-all.
• Nuestras propias bibliotecas se compilan y se distribuyen a una ubicación compartida donde los proyectos pueden hacer referencia a ellas. Depende del equipo de desarrollo de los proyectos decidir si quieren hacer referencia a un binario compilado o simplemente incluir el proyecto de utilidad en su solución.

Obviamente, la calidad del código que se encuentra en la biblioteca catch-all Utilities puede variar significativamente. Para aliviar esto, simplemente nos aseguramos de que dos personas de diferentes equipos de desarrollo revisaran todos los checkins al Utilities. ¡Esto elimina un montón de cosas que no tienen cabida allí!

Answer 5

Se considera un buen enfoque tener su propia biblioteca, ¡pero una línea de miles es una ruina!

Answer 6

Mire las "Confesiones de un vendedor de programas usados" de Will Tracz, y cosas del rabino de reutilización de HP, Martin Griss.

Answer 7

Durante años, Microsoft ha sido un gran defensor de lo que se conoce como software factories, una gran parte de la cual se dedica a resolver los problemas de la reutilización.

¿Cuáles son los problemas de la reutilización? Primero que nada, es difícil. Es muy difícil crear una biblioteca y API que sirva más allá de las necesidades inmediatas del proyecto en cuestión. ¿Cómo predice el futuro? Además, el problema de un depósito centralizado que sirve como base de conocimiento y como comunidad de práctica dinámica es muy desafiante. ¿Cómo se puede hacer algo que sea a la vez muy flexible y fácil de usar? Muchos han intentado y fallado. Tanto software factories como software product lines intentan resolver estos problemas.

¡Buena suerte!

Answer 8

Creo que un gran repositorio de código incluiría una herramienta CM y una herramienta Wiki. La herramienta CM debe estructurarse utilizando la idea de nivel (como usted propuso), ya que estructura el código por calidad. La wiki debe actuar como una "publicidad" de lo que el software puede hacer y cómo puede ayudarlo. Esta wiki también podría contener información como, qué proyectos están usando el código, la clasificación de qué tan utilizable es, y ejemplos de cómo usarlo. Si a alguien le preocupa que el equipo de desarrollo siga las pautas de nivel, se debe señalar cómo funciona la autocontrol y dar el ejemplo de qué tan bien 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 a qué se dedica cuando lo usa. Por ejemplo, si escribe una clase simple sin apenas comentarios y realmente no cumple con los estándares de codificación (tal vez un prototipo), entonces se ingresaría en \ sw_repository \ level0 \ ExamplePrototype.

Tal vez alguien tome ese fragmento de código y agregue comentarios y lo actualice a los estándares. Entonces esa persona lo colocaría en \ sw_repository \ level1 \ ExamplePrototype.

Luego, esa misma persona, un tiempo después, crea pruebas unitarias para el ExamplePrototype. Esto luego iría al nivel 2 y así sucesivamente.

La definición de los niveles debería tomarse un momento. Realmente deberían ser algo secuenciales e incluso si, por ejemplo, hubieras escrito pruebas unitarias para el código del prototipo pero no cumpliera los estándares de comentarios y codificación, entonces se colocará en el nivel 0 de todos modos. Sin embargo, sería fácil pasar al nivel 2 si dichos comentarios y estándares estuvieran satisfechos.

Answer 9

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

es decir, yo mismo tengo problemas para mantener mi propia biblioteca de reutilización. a veces hago una implementación que es muy específica de un proyecto, o hago el n-ésimo prototipo de alguna idea, y ninguna de ellas llega a mi biblioteca.

si realmente logras tener una biblioteca de reutilización de código, que muchos desarrolladores usan y mantienen de forma disciplinada, eso es una victoria. necesita un sistema de control de versiones y un rastreador de errores, el último utilizado tanto por los propietarios del proyecto como por los usuarios. necesitas comunicación y medios de contribución. tener un puñado de desarrolladores que usan un proyecto mejora drásticamente su calidad. la implementación mejora documentación es creada. API y diseño de características están en un nivel mucho más alto. un comité es algo bueno, pero no puede decidir qué tan bueno es el código, sin usarlo realmente. puede decidir si el código cumple con estándares específicos, pero cumplir con los estándares no es suficiente para buenas bibliotecas.

necesita hacer todo lo posible para asegurarse de que no tenga toneladas de fragmentos de código flotando, todos los cuales pueden hacer más o menos algo. bien, cualquier decisión de diseño tiene pros y contras, pero creo que tiene más sentido comenzar con UN proyecto para una tarea determinada y ramificarlo, 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 por categorizar la calidad de los diferentes proyectos. si un proyecto es malo, los usuarios/desarrolladores lo impulsarán a un nivel mejor. la mayoría de las personas son lo suficientemente inteligentes como para ver, cuando una biblioteca es buena y cuando no lo es. realmente necesita poner su energía en estos efectos simbióticos, en lugar de tratar de cargar a los participantes con reglas estrictas.

sólo mis 2 centavos ...;)