Community Translations of the Standard for Public Code

Contents

  1. Requisitos
  2. Por qué es importante
  3. Qué no hace
  4. Cómo probar o hacer tests
  5. Responsables de políticas y legislaciones: qué necesitan hacer
  6. Profesionales de la dirección de equipos: qué necesitan hacer
  7. Profesionales del desarrollo de software y diseño: qué necesitan hacer
  8. Más información

Contribute on GitHub

Documentar la madurez de la codebase

Requisitos

  • Una codebase DEBE de ser versionada.
  • Una codebase que está lista para ser usada DEBE únicamente depender de otras codebases que también se encuentren preparadas para su uso.
  • Una codebase que no está lista para ser usada DEBE tener una de las siguientes etiquetas:
    • prototype - para experimentar con el ‘look and feel’ y para probar internamente el concepto de las posibilidades técnicas.
    • alpha - para realizar pruebas o tests guiados con un limitado grupo de usuarios.
    • beta - para abrir las pruebas o tests a una sección más amplia del público general, poor ejemplo para probar si la codebase tiene potencial de escalabilidad.
    • pre-release version - código listo para ser publicado pero que no ha recibido aún una aprobación formal.
  • Una codebase DEBERÍA contener un registro de los cambios de versión a versión, por ejemplo en CHANGELOG.

Por qué es importante

Señalar claramente la madurez de una codebase ayuda a otros a decidir si reutilizarla, invertir en ella o contribuir a ella.

Qué no hace

  • Garantizar que otros usarán el código.

Cómo probar o hacer tests

  • La codebase tiene una estrategia de versionado que está documentada.
  • Está claro dónde conseguir la versión más reciente.
  • La codebase no depende de ninguna codebase marcada con un estado menos maduro.

Responsables de políticas y legislaciones: qué necesitan hacer

  • Entender que cualquier código desarrollado conjuntamente con políticas debe ser probado y mejorado antes de ponerlo en servicio.
  • Considerar la posibilidad de versionar los cambios de las políticas, especialmente cuando desencadenen nuevas versiones del código fuente.

Profesionales de la dirección de equipos: qué necesitan hacer

  • Asegurarse de que los servicios solo dependen de codebases de igual o mayor madurez que el servicio. Por ejemplo, no utilices una codebase beta en un servicio de producción ni una codebase prototype en un servicio beta.

Profesionales del desarrollo de software y diseño: qué necesitan hacer

  • Añadir una cabecera destacada a cada interfaz que indique el nivel de madurez del código.
  • Versionar todas las versiones.
  • Especialmente en escenarios de “rolling release”, la versión puede derivarse automáticamente de los metadatos del sistema de control de versiones (por ejemplo, utilizando git describe).

Más información