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.

En este post iré poniendo las instrucciones para instalar las aplicaciones básicas para disfrutar sin problemas de películas y videos en una caja Fedora.

Repositorio livna

Livna es un excelente repositorio para encontrar rpms de las aplicaciones multimedia.

Xine

Xine es un excelente player para ver videos y archivos de música en varios formatos.

Real Player

El Real Player nos permite ver videos en su formato y ver canales de televisión en línea.

http://www.real.com/linux/

Protectores de pantalla OpenGL

Casi siempre me falta instalar los protectores de pantalla OpenGL que son muy llamativos y dejan a las visitas impresionados.

Sin duda, lo mejor después de terminar un videojuego es disfrutar de un delicioso pastel de chocolate. Desafortunadamente, el premio más codiciado por los "gamers", el Pastel Portal de Valve, no es nada fácil de conseguir. Es el "Santo Grial de los pasteles" porque muchos dudan de su existencia y creen que todo lo que se habla de él es una mentira. Incluso hay quienes piensan que sus ingredientes son secretos y que pueden ser mortales tanto para quien lo come como para quien lo prepara. Sin embargo, en este post presento una recreación segura de como sería este singular pastel en su versión de chocolate.

Ingredientes

150 gramos de Mantequilla.

5 Huevos.

115 gramos de harina.

145 gramos de azúcar.

30 gramos de cocoa

3/4 de cucharada de Bicarbonato.

1/4 de litro de crema para repostería sabor chocolate.

Granillo de chocolate.

3 Huevos (?).

8 Cerezas.

Crema chantilly.

Procedimiento

1. Batir la mantequilla junto con las yemas y el azúcar hasta cremar muy bien.

2. Cernir aparte la harina, cocoa y bicarbonato.

3. Engrasar y enharinar 1 molde redondo de 22 centímetros de diámetro.

4. Precalentar un horno a 350°F/180°C.

5. Una vez lista la mantequilla, se le añade la mezcla de la harina, cocoa y bicarbonato y se bate a baja velocidad hasta que se incorporen los ingredientes.

6. Se agregan las claras batidas previamente a punto de turrón de manera envolvente usando una espatula hasta que esté totalmente incorporada la mezcla.

7. Se vacía la mezcla al molde y se deja hornear por 45 minutos.Sacar y dejar enfriar sobre una rejilla.

8. El pan se corta en tres partes iguales.

9. Batir la crema sabor chocolate.

10. Rellenar cada capa del pastel con la crema, cubrir por fuera y alisar.

11.Espolvorear con el granillo.

12.Ponga crema chantilly en una manga con duya y decore con 8 rosetas, y al terminar coloque las cerezas en cada una de estas.

13. Poner otra roseta en el centro del pastel y coloque la vela.

14. ¡Provechito!

Cuando comencé a estudiar OpenGL para exportar modelos tridimensionales de blender a un programa de simulación escrito en C++ que estaba escribiendo, utilicé primero un programa de un sólo archivo para hacer pruebas rápidamente para después implementarlo ya de manera formal. Esta forma de trabajo me ha funcionado muy bien porque puedo dejar guardados varios archivos con distintas pruebas de concepto que me pueden servir para dar clases o refrescar rapidamente mi memoria en vez de andar buscando y recordando ¿dónde use eso?.

Simple pero efectivo

Los fuentes del programa se pueden encontrar aqui: Código Fuente.

Páginas: 1 2

Un juego multiusuario en java de Mayo de 2001.