Blog de Jorge Machín

En este post dejo unas reglas simples que he utilizando con el paso del tiempo y que me han funcionado para escribir programas con menos errores.

1. Reconocer que errar es humano

El primer consejo para controlar el número de errores en nuestro código, es reconocer que somos humanos y podemos cometerlos en cualquier momento. Por lo general, no es constructivo buscar culpables si no hay detrás una conducta crónica o casos evidentes de negligencia. La conducta correcta es crear las herramientas y metodologías que pueden reducir el riesgo de este hecho.

2. Probar, probar y probar

Uno de los elementos básicos del control de calidad son las pruebas al producto. Se debe revisar de forma ordenada el funcionamiento de los programas de principio a fin.

Por lo general, es recomendable que una persona ajena al diseño del proyecto también realice las pruebas, pues los programadores y diseñadores pueden estar ciegos a ramificaciones inesperadas al tener la tendencia natural de revisar los programas siguiendo el flujo de los algoritmos o bien con el mismo camino que utilizaron al programarlo.

Es recomendable apuntar o automatizar las pruebas en donde se tienen errores comunes o ratas complicadas para que sea lo primero que se revise para disminuir las iteraciones durante el proceso de control de calidad, o bien, se olviden de hacerlas.

Cuando el programa es suficientemente grande o involucra a varias personas, se recomienda tener un sistema centralizado donde se pueda reportar los errores y darles un seguimiento hasta su corrección.

3. Todo error se debe perseguir de oficio

Un reporte de error siempre es cosa seria. Generalmente, no es válido ignorarlo porque sólo le ocurre a un usuario o en una máquina en particular; hay que tener presente que si el error le ocurrió a alguien, le puede pasar a varias personas.

Si no se sigue este punto, quizás el error no haga estallar nada, pero puede aparecer en una demostración ante un posible cliente, creándonos mala reputación e incluso su perdida.

4. Un error emulado es un error corregido

Cuando un error se puede repetir fielmente es posible seguir trazas, colocar banderas de depuración o analizar la lógica hasta llegar a él. En teoría, si somos capaces de reproducir un error, deberíamos estar tranquilos porque estamos a unos pocos pasos de su solución.

5. Cuando ocurre un error, uno debe preguntarse: ¿Porqué ocurrió?, ¿qué se puede hacer para evitar que ocurra el mismo tipo de error en situaciones semejantes?

Este consejo es la parte medular para evitar errores. Si estamos cometiendo demasiados errores es porque seguramente llevamos una mala metodología y es el momento adecuado para detenernos a recapacitar en la forma de como se está trabajando.

6. Si un error aparece dos veces en un mismo lugar, es mejor re-escribir el código de otra forma o bien agregarle algo para evitar que pueda ocurrir de nuevo.

7. Para evitar errores al usar funciones, clases, etc; estas deben validar las entradas

Los errores no sólo pueden estar en nuestras funciones, sino en los programas que las utilizan. En grupos de trabajo es común que se pierda tiempo innecesario revisando funciones que no tienen errores y ya están revisadas porque presentan síntomas que apuntan a ellas cuando son los parámetros de entrada los que están mal.

8. Los programas deben registrar los errores en una bitácora (log)

Un error que nadie atestigua, no existe en nuestras mentes. Por eso, es muy importante agregar medios de monitoreo y registro de condiciones y situaciones anómalas para su posterior análisis. Si el error no puede reproducirse manualmente, con el tiempo y ayuda de banderas es posible darle seguimiento haciendo trazas hasta encontrarlo. Es muy importante que el mismo programa trabaje por nosotros y sea nuestro testigo de calidad en la busqueda de errores.

Sin entrar en mucho en detalle, los programas que utilicen técnicas de orientación a objetos se pueden usar "profilers" para contar el número de objetos que estamos creando y así ver si tenemos fugas de memoria o estamos desperdiciando recursos.

9. Si se tiene una solución complicada a un problema; seguramente no es la adecuada o va a provocar errores después.

Algoritmos complicados, trucos de programación o una solución estrafalaria, seguramente con el tiempo provocará errores y pérdida de tiempo a programadores inexpertos o a nosotros mismos después de algún tiempo. Es mucho mejor la programación "aburrida" donde uno ya sabe que va a pasar con solo ver unas pocas líneas de código.

10. Si no está roto, no es necesario arreglarlo

Esta regla es especialmente válida con código antigüo.

11. Tener código autodocumentable

La documentación en papel no se puede sustituir, pero tenerla dentro del mismo código es una buena costumbre para evitar errores al tener a la mano advertencias, rangos y cualquier otro tipo de información.

12. Leer o hacer pruebas de escritorio a nuestro código una vez que esta listo

Una vez que todo esta en su lugar y en perspectiva, es posible detectar faltas en los estándares, casos validados incorrectamente, código repetido y errores en la lógica. Es mejor si lo puede revisar rápidamente otra persona.

13. Cuando no encuentres un error, es buena idea platicarlo con alguien

Curiosamente, muchas veces me ha pasado que al explicar el problema un compañero de trabajo, he encontrado la causa del error dentro de mis propias palabras pues al acomodarlo mentalmente se acomoda y repite la lógica. Además una mente externa suele tener mayor perspectiva.

14. La documentación debe incluir una bitácora de cambios al código que además registre los errores encontrados y sus correcciones

Al llevar un registro de los cambios es posible identificar históricamente a partir de que cambio surgió un error. Lo cual nos permite regresar a una versión anterior o darnos una idea de donde podemos empezar a buscar.

Nota:

Obviamente estos son consejos que pueden llegar a generar controversia y no son válidos en todos los contextos, metodologías o lenguajes de programación y no está por demás aclarar que al igual que otros de mis posts que estas reglas irán creciendo y puliendo con forme vaya teniendo tiempo libre.

Aquí los he presentado de forma sencilla, pero muchos de ellos estan basados en algunas metodologías como programación extrema, fábricas de software, programación por contrato y otros que le recomiendo al lector que se familiarice con ellos.