Buenas prácticas en la programación

Autores como Dave Thomas, Martin Fowler, Kent Beck, Robert Cecil Martin o Rebecca Wirfs-Brock coinciden en unas prácticas que un desarrollador debería seguir o que un programa debería contener:



1) El principio DRY, 'Don't Repeat Yourself' o 'No te repitas'. Citado por primera vez por Dave Thomas en su libro The Pragmatic Programmer. Este principio se resume en que a menudo, nuestro código repite sentencias o trozos de código para un mismo fin. Cuando veamos que esto ocurre, saquemos estas sentencias e introduzcámoslas en una función, si esta función la utilizamos muchas veces, encapsulémosla en una clase. Si esta clase junto con otras dan una solución a un problema repetido, hagamos un patrón de diseño, y así sucesivamente. El fin es no 'reiventar la rueda', pilar en la programación orientada a objetos.



2) Usar Refactoring. La definición formal de refactoring es 'el proceso por el cual cambiamos y mejoramos el software internamente sin que halla una alteración exterior en el comportamiento del mismo'. Este término fue oficialmente explicado por primera vez en 1999 por Martin Fowler en su libro Refactoring: Improving the Design of Existing Code. Si no lo has leído, te lo recomiendo.
En definitiva, el proceso de refactorizar un programa hace que éste sea mucho más legible, más limpio y más reusable sin que cambie la ejecución del programa. Primero se escribe el código y luego se refactoriza.
Es un conjunto de técnicas sencillas como por ejemplo acortar un método demasiado largo, cambiar su nombre para que realmente refleje lo que hace, colocar los métodos en las clases adecuadas, quitar parámetros cuando no hagan falta, etc. Seguramente te preguntarás para qué sirve cambiar de nombre una función o una variable si leyendo el código puedes intuirlo. Bien, los programadores además de programar, leemos mucho código. En un equipo de trabajo, la revisión de un programa escrito hace un año por un programador que puede estar ahora de vacaciones se puede complicar si tenemos variables llamadas como x, a[5], temp o FX45, funciones extralargas y clases cuyo nombre no reflejan su intención. Mucho más fácil es leer: altura, tiempo o articuloEnAlmacen. Si eres altruista mira por los compañeros y deja un código legible, si no lo eres, piensa que más tarde o temprano tendrás que revisar tu programa y te costará mucho más tiempo saber cómo funciona.

3) Testear. Hacer tests o pruebas sobre tu programa no se limita a que responda bien a un evento. Cuando hacemos click y se abre una ventana o se muestra un subtotal de una lista de precios estamos limitando el testeo. Testear en software lleva parejo técnicas como Unit Testing, Test-Driven Development, Mock Objects, Automatic Testing, etc. Todas ellas englobadas por primera vez en la metodología XP desarrollada por Kent Beck.
El testeo asegura la calidad del software y una disminución en la propensión a errores. Se prefiere hacer buenos tests a estar toda una mañana buscando un bug con un debugger.
Pero, ¿qué es hacer un testeo? Bien, testear, en su manera más formal, es hacer pruebas sobre un método o clase (no sobre la ejecución del programa) y que ésta responda tal como lo habíamos planeado.
Por ejemplo, cuando hagamos una función que calcule la raiz cuadrada de un valor, debemos comprobar que realmente devuelve un valor esperado, y, lo más importante, debemos pasarle como argumento valores posibles, imposibles y no contemplados. Me explico: el valor posible para una raiz cuadrada es un entero o un decimal positivo, un valor imposible un entero o decimal negativo, y un valor no contemplado podría ser un caracter alfanumérico, una cadena, una pulsación de una tecla o un valor nulo.
Aparte de las pruebas unitarias, también completaremos el testeo con una buena supervisión de la ejecución del programa, tanto a nivel de programador como a nivel de usuario.


¿Porqué estas prácticas? La razón es que el desarrollo del software es una disciplina que exige una contínua revisión. Un programa siempre tiende a la entropía, al desorden, si no se mantiene, se limpia y se cuida. Muchas veces hemos empezado a idear un programa, funciona idílicamente en nuestra cabeza, todas sus partes combinan perfectamente, esto devuelve tal cosa, aquello se une con esta otra... Empezamos a programar y a medida que el tiempo pasa, nuestro pograma se vuelve inestable: aquello que funcionaba perfectamente en nuestra temprana planificación se va desmoronando. 'Uy! no había contemplado esto!' 'Uy! ¿porqué no me muestra el valor?'
Todo esto a nivel individual y con un programa propio. Llevado a términos empresariales, con un gran equipo, y donde el dinero y los costes juegan un papel muy importante, las consecuencias son desastrosas. La solución es aplicar estas prácticas que se han englobado en las denominadas metodologías ágiles. Todas estas metodologías tienen como base lo descrito con sus diferencias propias. Aunque esto ya es harina de otro costal y se comentará más adelante.