Ir al contenido principal

Adicción a la Refactorización

Siempre que trabajo en una nueva característica, para algún proyecto, modifico el código antes de entregarlo. Tratando de hacerlo más compacto y/o fácil de leer. Esto con la intención de mejorar la calidad del código.

También cuando necesito modificar cierta funcionalidad existente, cambio el código antes de implementar los cambios. Con la intención de entender mejor la funcionalidad actual y así dejar todo listo para realizar los cambios que se requieren implementar. Una vez hechos los cambios vuelvo a buscar áreas donde haya oportunidad de refactorizar…hasta ahí creo que todo va bien. El problema viene cuando se convierte en una especie de adicción.

Hay ocasiones que al trabajar en alguna característica determinada me encuentro con algún trozo de código “malo” que no esta relacionado con lo que estoy trabajando y aun así siento la necesidad de modificarlo. A veces logro aguantarme las ganas; pero otras veces simplemente no puedo evitarlo. También me pasa cuando algún compañero de trabajo me pregunta  algo especifico y al mostrarme el código quiero empezar a modificarlo, cuando ese no es el punto de la pregunta que me hicieron. Aunque estoy tratando de que el código sea mejor, puede convertirse en un problema.

A veces no se si lo hago por el proyecto o lo hago por mi. El código “malo” puede ser mucho, por lo tanto requiere algo de tiempo. Aunque hay herramientas que ayudan con la refactorización (ya sea como parte del IDE o como plugins), aun así es tiempo que le estoy quitando a tareas que el cliente espera y que están pendientes por realizar.

Estoy convencido de que La refactorización constante ayuda a la calidad del código, mantiene activo al proyecto, previene en cierta medida que el proyecto se vuelva legacy. Pero también debo aceptar que existe código que se puede mejorar y que esta bien (si funciona) dejarlo así como esta. Aunque sea difícil de vencer la tentación de mejorarlo. Es importante enfocarse en las tareas que le dan valor al usuario y en ocasiones la refactorización no da ese valor.

Como en todo lo demás: “Es bueno el uso; pero no el abuso”.

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