Ir al contenido principal

Código hediondo

Hay ocasiones en que el código huele mal, es a lo que se le llama code smell. El termino que encontré en español es "código hediondo". No es código que tenga un error obvio, el código que huele mal no necesariamente está mal; pero debes darle una revisada y quizás reescribirlo  porque generalmente cuando hay mal olor significa que algo se está "echando a perder".

Cuando veas código que huele mal... sí, el olor del código se ve, incluso se puede detectar mientras se escucha al código... bueno, decía que sí ves código que huele mal, cámbialo en el momento, no lo dejes para después porque si trabajas mucho tiempo con código que huele mal, puedes acostumbrarte al olor y después no darte cuenta de que tu código apesta.



Algunos de los malos olores en el código son:

Código Duplicado
El código duplicado no es en sí un error. El problema es que no ayuda al mantenimiento del código. Hace que sea fácil cometer errores en el futuro, además de que te llevará más tiempo modificarlo. ¿Te ha tocado hacer un cambio en un programa y tener que ir a muchos partes del código a hacer el mismo cambio? No solo te tardaste más, también existe la posibilidad de que hayas olvidado cambiarlo en algún otro lugar y por lo tanto has introducido un  error.

Para prevenir el código duplicado, lo que puedes hacer es que cuando necesites que se ejecuten instrucciones en varios lugares, en lugar de copiar y pegar, mejor corta y pega. Corta la parte que se repite, pégala en un nuevo método, lo que cambia lo defines como parámetros y mandas llamar (o ejecutas) ese método donde lo necesites.

Método muy largo
El problema con los métodos largos es que es difícil leer que es todo lo que hace. Se complica poder entenderlo y por lo tanto lograr notar a simple vista como puedes afectar la funcionalidad del método al introducir un cambio.

Si el método hace muchas cosas es mejor llamar a otros métodos que hagan una parte chica cada uno. Por ejemplo: si tienes un método que genera un archivo con mucha información (como la factura electrónica). En lugar de tener todo el código en el mismo método, puedes dividirlo en métodos que escriben cada parte del objeto al archivo (un método para escribir los datos del emisor,  receptor, otro para productos, etc.).

Función con muchos parámetros
Este es un mal olor que se va dando con el tiempo, empiezas con uno o dos parámetros y todo se ve bien, luego agregas funcionalidad, necesitas más información  y le vas agregando más y más parámetros y a veces algunos de esos son opcionales. Al final puedes terminar con un método (o función dependiendo como le llame el lenguaje) que recibe muchos parámetros. No es un error; pero puede hacer más difícil entender el código.

Lo que puedes hacer es que cuando empieza a crecer el número de parámetros, en lugar de recibir muchos parámetros, recibir uno solo, un objeto o estructura con atributos (o propiedades) para cada posible valor. Algo como lo que hace jQuery (por ejemplo) con la función ajax, en lugar de recibir muchos parámetros, recibe un solo objeto con atributos para cada opción esperada.

Magic Strings
No solo aplica para las strings, también para los números. Las magic strings son valores literales que aparecen en el código. Por ejemplo cuando en ASP.NET tienes algo como [Authorize(Role = "Administartor")] si te fijas escribí mal el nombre del rol Administrator y no me voy a dar cuenta hasta que vea que todos los usuarios pueden acceder a ese recurso (no solo los que tengan el rol administrador). Con los números el problema no es que lo escribamos mal, sino que no sabemos qué es, si tenemos algo como if order.status = 2 then  es difícil saber qué significa ese 2 por lo tanto si quiero modificar el código debo tener cuidado.

El uso de constantes para los strings y el de enums en los enteros ayuda a prevenir este feo olor. Usa cosas como [Authorize(Role = Role.Administrator)] porque así si lo escribes mal puedes darte cuenta en tiempo de compilación. Tener cosas como if order.status = OrderStatus.InProgress then hace que sea fácil de saber que está pasando en el código.

Complejidad innecesaria 
Es como cuando usas una bazuca para matar una mosca. La complejidad innecesaria hace que el código sea más difícil de seguir, de entender y de modificar. El desarrollo se vuelve más lento y sin ningún beneficio. Este olor puede ser difícil de detectar, más por uno mismo. Es como la persona que se pone mucho perfume pero no se da cuenta porque siempre se pone y ya se acostumbro. No es que huela feo; pero no es agradable el perfume en exceso.

Algunos proyectos son más complejos que otros; pero no debes empezar de lo complejo a lo simple, sino al revés (para seguir con la metáfora, no te puedes ir quitando perfume). A veces sí ocupas dividir tu proyecto en varias capas; pero ve agregándolas cuando sientas que lo necesitas. No empieces agregando capas solo porque sí, después es más difícil quitarlas.

Estos son algunos de los olores que identifico, hay más; pero hasta aquí la dejamos por hoy. Mantén tú código oliendo bien, evita el código hediondo.



Comentarios

Entradas más populares de este blog

Bloqueos

Una de las preguntas típicas de las juntas matutinas en los equipos de desarrollo de software es ¿Hay algún bloqueo? Si lo hay, se trata de ver qué es lo que está esperando esa persona y encontrar la forma de que se desbloquee; pero ¿Qué son los bloqueos? Los bloqueos son obstáculos que te impiden realizar o avanzar en tu trabajo. Evitan que puedas seguir progresando en el proyecto.

He notado que es común en las personas con menos experiencia decir que tienen un bloqueo cuando están batallando, debido a su poca experiencia, en la forma de resolver un problema. Han intentado varias formas y se empiezan a quedar sin ideas de como puede ser resuelto el problema o como pueden cumplir con el requerimiento especificado. Al quedarse sin opciones de qué intentar dicen que tienen un bloqueo con la tarea y que a menos que alguien les diga como resolverlo, no se puede avanzar en la tarea.

En personas con más experiencia, ese tipo de bloqueos no ocurren, una persona con experiencia ha visto pro…

Firebird 2.1 UPDATE OR INSERT

Another great feature that I like in Firebird 2.1 is the UPDATE OR INSERT statement. It's a really time saver and it makes the SQL cleaner.

For example suppose I have a products table like the one I use in my last post and an inventory table to store the product stock. Before Firebird 2.1 if I want to set the stock for a product I needed to check if a record for that product_id already exists; if the product_id already exists then I write an update. If not then I write an insert statement. So I ended up with something like this:


IF EXISTS(SELECT * FROM inventory WHERE product_id = :product_id ) THEN
UPDATE
inventory
SET
stock = :stock
WHERE
product_id = :product_id;
ELSE
INSERT INTO inventory
(product_id, stock)
VALUES
(:product_id, :stock);

In this example I only update one field but when I have to update a big table I ended up with a big chunk of code and thinking: "there should be another (better) way to do this".

Fortunately now with Firebird 2.1 there…

Database Mail en MS SQL Server 2005

Configuración de Database Mail en MS SQL Server 2005

Primero se debe de habilitar, ya que por omisión el componente esta deshabilitado, Utilizando el SSMS (SQL Server Management Studio)


Si no esta habilitado aparecerá un mensaje preguntado si lo habilita, después aparece esta ventana donde se pregunta al usuario que es lo desea hacer.


Seleccionamos la primera opción para crear un perfil.


Configuramos el perfil y le agregamos por lo menos una cuenta.


Seleccionamos el perfil como public y default.


Para mandar correo se utiliza el procedimiento msdb.sp_send_dbmail por lo tanto el usuario que intente mandar correo debe de tener permiso para la base de datos msdb.

Referencias:
http://www.sqlservercentral.com/columnists/cBunch/introtodatabasemailinsql2005.asp