¿Cómo pueden los proyectos de fuente abierta mantener su calidad?

Como en todo proyecto, en el que participa mucha gente, con diferente experiencia y conjunto de habilidades, se debe mantener cierta estandarización [1]. De lo contrario, cada parte del producto / código se vería totalmente diferente; el futuro desarrollo será una pesadilla y un error, probablemente.

Base de conocimientos
Debe haber un lugar para mantener estándares de proyecto bien redactados. La forma común es usar algún tipo de wiki para ello. También le permite manejar y rastrear fácilmente los cambios en él.

Estándares de codificación
1. Hay algunas bases, como los estándares de codificación y los procedimientos de desarrollo.
2. Una vez definido CS, es posible automatizar la tarea de verificar si el código recientemente confirmado es consistente
3. Las verificaciones se pueden realizar por integración continua (por ejemplo, Jenkins) en cada solicitud de fusión

Automatización
Como escribí anteriormente, la clave en un entorno tan impredecible (= muchas personas al azar pueden estar involucradas) es automatizar tanto como sea posible. A medida que el proyecto crezca, es posible que no pueda controlar todo manualmente.

La implementación de la integración continua permitirá automatizar verificaciones de estándares de codificación, pruebas unitarias, pruebas funcionales o incluso comprobaciones de seguridad [2]

[1] http://labs.octivi.com/maximizin …
[2] http://labs.octivi.com/continuou …

No es muy diferente del software patentado de código cerrado. Recuerde, los programadores de código abierto y el control de calidad también suelen ser profesionales. Están familiarizados con una amplia gama de técnicas de Extreme Programming y prácticas ágiles. Harán revisiones por pares, pruebas unitarias, tendrán automatización de pruebas para pruebas de sistema y rendimiento, usarán herramientas de escaneo de códigos para análisis estáticos, etc.

Además, aunque cualquier persona puede contribuir a un proyecto de fuente abierta, no todas las contribuciones se promocionan automáticamente en el repositorio principal del código fuente del proyecto. Solo un subconjunto de contribuyentes, a menudo llamados “committers”, tienen acceso directo para integrar sus propias contribuciones. Los committers generalmente son los desarrolladores más confiables y experimentados que han demostrado su comprensión de la base de código y su capacidad para escribir un buen código. Todos los demás envían parches que luego se revisan antes de comprometerse.

En cuanto a obtener suficiente tiempo de QA para un lanzamiento, depende del proyecto. Trabajé en algunas de las pruebas de unidad que tenían una cobertura de código de alto nivel. Cada vez que encontramos un nuevo error, escribimos una nueva prueba de unidad que fallaría y solo pasaría cuando se solucionara el error. Logramos un alto nivel de calidad a pesar de que no teníamos probadores que no fueran desarrolladores. Y he trabajado en otros proyectos en los que confiamos en un gran número de voluntarios de QA y casi no tuvimos pruebas de unidades.

En general, reiteraría la sabiduría de “cada clase nueva de usuarios encuentra una nueva clase de defectos”. Por lo tanto, recomiendo no confiar por completo en un solo enfoque, sino utilizar una combinación de enfoques.