kwalitee

Término de moda inicialmente, se está convirtiendo en un fin en sí mismo para fortuna de desarrolladores y usuarios de software escrito en Perl.

Como autor de algunos módulos del CPAN el que exista un sitio donde se mida este valor para mis escritos es muy estimulante, sobre todo viendo que no estoy nada mal en las puntuaciones (fallo en un par de aspectos, que encima son opcionales, aunque uno de ellos es que alguien use mi módulo y eso es difícil de conseguir).

:-)

¿ Qué es kwalitee ?

A lo que íbamos, kwalitee es algo impreciso, no cuantificable, que posee una pieza de software y que la caracteriza como de calidad. Se define, eso sí, por un juego de reglas cuyo cumplimiento sí es medible, por lo que al final es factible proporcionar un valor al conjunto.

Resumiendo, la kwalitee es algo que se reconoce de un vistazo, pero no puede explicarse exactamente.

Propósitos

Para que un software sea de alta calidad debe cumplir una lista de requisitos globales que paso a transcribir a continuación, comenzando por la lista oficial del --cpants-- y continuando con la que se ofrece en el wiki del grupo de calidad de Perl.

Requisitos en CPANTS

1. extractable: Debe estar empaquetado en algún formato reconocible (tar y gzip principalmente).
2. extracts_nicely: Debe poder desempaquetarse en su propio directorio, sin ensuciar el de trabajo.
3. has_readme: Debe contener un archivo README que describa información básica para usar antes de descargar e instalar el software.
4. has_manifest: Debe incluír un manifiesto del contenido.
5. has_meta_yml: También debe estar un archivo META.yml correcto, ya que se de mucha ayuda, ó indispensable en ocasiones, para las herramientas automatizadas de mantenimiento e instalación de módulos.
6. has_buildtool: También debe tener una herramienta para su construcción e instalación (Makefile.PL ó Build.PL principalmente).
7. has_changelog: Debe contener un registro de cambios en el software (archivo changelog) que ayude a decidir si merece la pena ó no, ó las consecuencias de, actualizar el software.
8. no_symlinks: No debe contener enlaces simbólicos, puesto que hay sistemas operativos que no los contemplan y de estar forma pierde en portabilidad.
9. buildtool_not_executable: El programa de construcción no debe ser ejecutable.
10. has_example (opcional): La distribución no contiene ejemplo alguno de cómo se puede usar.
11. has_version: El nombre del archivo en el que viene empaquetado el software no contiene un número de versión, ó algo que se parezca razonablemente, tal y como trata con ello CPAN::DistnameInfo.
12. has_proper_version: el número de versión no es un número como tal. Probablemente incluya alguna letra delante.
13. metayml_is_parsable: el archivo META.yml de la distribución debe poder ser analizado con la versión de YAML que está usando el --cpants--.
14. metayml_has_license: se debe incluir la licencia del software en el archivo META.yml.
15. metayml_conforms_spec_1_0: la estructura del archivo META.yml debe ser conforme, al menos, a la versión 1.0 de dicha especificación.
16. metayml_conforms_spec_current (opcional): es un plus el que dicho archivo META.yml sea conforme a la especificación actual utilizada en el --cpants--, que a día de hoy es la 1.2.
17. proper_libs: Es un error que exista más de un archivo .pm en el directorio base, ó que los módulos .pm no se incluyan en un directorio lib.
18. no_pod_errors: Una distribución no debe contener errores sintácticos en la documentación POD de sus archivos. Estos son todos los .pl, .pm y .pod que encuentre, incluyendo aquellos del directorio de tests t/.
19. is_prereq (opcional): Es un plus que la distribución sea requerida por otra.
20. has_working_buildtool: Este programa constructor debe ser funcional, y no basarse en código exterior muy antiguo (especialmente Module::Install anterior a 0.61).
21. use_strict: la distribución debe utilizar la directiva strict en todos sus módulos.
22. has_test_pod: No se incluye un test para verificar la documentación POD (ver Test::Pod).
23. has_test_pod_coverage: No se incluye un test para comprobar la cobertura de la documentación sobre el código.
24. has_humanreadable_license: No se encuentra una licencia definida en la documentación, ó en un archivo llamado LICENSE.
25. manifest_matches_dist: El manifiesto debe reflejar fielmente el contenido y no tener omisiones ó errores.
26. no_cpants_errors: Esta condición se cumple cuando existe errores en el ejecución de los tests por parte de --cpants-- porque, ó bien el propio --cpants-- contiene errores, ó bien el paquete incluye cosas muy extrañas que hacen que fallen.

Requisitos en qa-perl

Ellos lo definen como un brainstorming en el que van apuntando aquello que consideran debe añadirse a los requisitos de un software de calidad.

• Fácil de instalar
• Los términos en los que se licencia deben ser claros.
• Debe tener un propósito definido y conciso
• Su estado de desarrollo debe especificarse correctamente, sin equívocos.
• El interfaz de uso debe estar documentado
• La documentación debe ser legible
• Debe funcionar tal y como se espera
• El comportamiento del software debe ser el indicado en la documentación.
• No debería interferir con software de terceros con el que no tenga relación.
• Debería hacer algo útil
• El mantenimiento debe ser fácil (ó al menos posible).
• Debe funcionar :-)
• El código debería seguir algún estándar ó normativa
• El interfaz público debe ser estable
• El código, también, debe ser legible
• Debe estar publicado
• El autor debe estar abierto a sugerencias y mejoras en su código.

Enlaces

• Definición de kwalitee hecha por los hoplitas.
• Dedicada a ella, el wiki del grupo de calidad de software de Perl, dispone de una página hablando sobre los propósitos de ella.
• El propio --cpants-- conserva las descripciones de todos las medidas, para poder explicar qué falla en un módulo cuando informa sobre él.