Diagnósticos vs Certificados II

En un post anterior exponía mi rechazo general a esas cosas llamadas certificados. Ahora me gustaría regresar el tema al contexto del desarrollo de software, en particular, a las evaluaciones de métricas de código.

 

Si usted trabaja con alguna metodología de desarrollo, seguro utiliza alguna herramienta de versionamiento, nosotros en perNodis usamos Subversion, pero para el caso que nos ocupa todas funcionan más o menos igual.

Sin embargo, el puro versionamiento no es suficiente. Si queremos tener un poco de métricas que nos permitan saber cuánto nos tardamos en desarrollar algo, o lo que es lo mismo, poder dar mejores estimados de tiempo y costos, y tener una mejor planeación de recursos, necesitamos hacer algo más con nuestro código que sólo versionarlo.

El primer paso en el uso de métricas es la aplicación de una de las más elementales y también una de las más criticadas de estas: la cuenta de líneas de código (SLOC), por unidad de tiempo, por desarrollador y por proyecto. Aquí es donde las cosas comienzan a ponerse feas si confundimos los certificados con los diagnósticos.

La cuenta de líneas de código no nos dice si esas líneas son eficientes, si no tienen errores, si tienen mucho trabajo intelectual detrás, no nos dicen nada acerca de la calidad en sí del código, sólo nos dicen cuántas líneas fueron producidas en cuánto tiempo por qué programador. Si consideramos esta cuenta como un certificado de productividad, estaremos cometiendo un grave aunque común error de administración de proyectos de software.

La cuenta de líneas nos da un diagnóstico que podemos usar en nuestros estimados y en nuestras evaluaciones de productividad, pero debemos saberla leer y para ello debemos saberla combinar con otras métricas y con apreciaciones subjetivas (ni modo, mientras seamos y trabajemos con personas, tendremos que vivir con la subjetividad).

Supongamos que todo va marchando y que no hemos malinterpretado nuestra modesta métrica de líneas de código. Ahora queremos observar con qué seguridad vamos avanzando en el desarrollo, o más precisamente, cómo está la cobertura de nuestro código, es decir, qué porcentaje de nuestro código está probado con pruebas unitarias automatizadas.

El porcentaje de cobertura por pruebas unitarias es otra métrica diagnóstico bastante sencilla que muchos equipos solemos poner en práctica en nuestros procesos de integración continua, pero que también puede confundirse con un instrumento certificador.

La métrica de cobertura nos dice qué tan probado está un código, pero no nos dice si estas pruebas están bien hechas, si realmente garantizan el comportamiento de nuestro código. En ocasiones algunos programadores escriben pruebas cuyo único fin es elevar el porcentaje de cobertura sin preocuparse por el comportamiento que están probando, sólo se fijan en las líneas marcadas por la herramienta de cobertura y se ingenian una prueba que “pase” por esas líneas antes ignoradas. En escenarios así, la métrica de cobertura pierde su sentido y su validez.

La métrica de cobertura es un diagnóstico que nos da una idea de qué tan probado está el código, de qué tan cuidadosos hemos sido con el código y las pruebas que hemos escrito en función del sistema, y no del código escrito sólo para cumplir una norma, para certificar que nuestro código tiene una cobertura del 98% por decir algún número.

Podríamos seguir con las pruebas de complejidad ciclomática, cuenta de líneas duplicadas, violaciones de buenas prácticas según FxCop, etc. Con todas estas herramientas pasa lo mismo. Siempre es posible escribir código para las métricas, código que esté dentro de la “norma de calidad” sin importar si se trata de código eficiente o realmente fácil de leer o seguro o bien diseñado.

Cuando las métricas de código son usadas como un instrumento de certificación, dejamos de escribir el código en función del sistema que estamos desarrollando y nos concentramos en pasar las pruebas. Incluso es posible que logremos hacer un código con errores y completamente alejado del modelo que debe reflejar, pero con evaluaciones impecables en cada una de las métricas usadas.

Soy un defensor del uso de métricas y herramientas de control de calidad, siempre y cuando sean utilizadas como formas de diagnosticar el código y el trabajo que realizamos, y no como una “norma” que hay que cumplir o un certificado que hay que obtener.

Y es que, al final, el software lo hace la gente y lo más importante para conseguir un software de calidad es que esa gente, los desarrolladores, estén comprometidos con la calidad. Como bien dice Marco Dorantes, las metodologías debieran ser un compromiso personal con valores y principios, y no sólo una verborrea llena de numeritos y cuantificaciones.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s