Buenas Prácticas: Uso de constantes para URL's

Tras la vuelta de vacaciones el volumen de trabajo no me deja dedicarle mucho tiempo al blog, pero a pesar de eso voy a intentar incorporar aunque sea pequeños artí­culos que le sigan dando la vida suficiente.
Para hoy un pequeño truco que actíºa como buena práctica en proyectos de tipo web ASP.NET (y otras tecnologí­as web).
Es muy comíºn que a la hora de viajar entre páginas de un mismo proyecto, se utilice la instrucción correspondiente de redirección poniendo directamente la URL de la página. Algo así­ como (código C#):
response.redirect(“~/mantenimiento/coche.aspx”);
Esto en principio no tiene mayor problema, pero, podemos añadirle una cierta y sutil mejora:
response.redirect(ConstantesURL.MANTENIMIENTO_COCHE);
Siendo “ConstantesURL” una clase que contiene las constantes que almacenan las URL de las diferentes páginas que componen la aplicación.
Esto puede parecer una tonterí­a, pero nos protege de forma muy sencilla de los posibles cambios de rutas de páginas que pueden sucederse a lo largo de la vida del proyecto. Es muy comíºn que ante una mala definición inicial, o de un crecimiento inesperado del volumen de páginas, se tenga que restructurar la organización de carpetas. Mediante este método, el coste es muy similar al de hacer un refactoring de un paquete, evitando así­ los tí­picos problemas de ir revisando uno a uno todos los enlaces y corrigiendo el viejo enlace por la nueva ubicación.
Saludos.
Miguel.

Buenas Prácticas: La Importancia de los Comentarios

Poner comentarios en un código siempre se ha considerado por la mayorí­a como una labor aburrida, tediosa, poco motivante en general.
Luego está el otro extremo, los que se dedican a poner parrafadas de libro en cada lí­nea o en la descripción de los métodos.
Como siempre, los extremos no suelen ser las mejores soluciones. Lo recomendable es siempre comentar, pero a ser posible sin redactar el quijote por cada método o trozo de código. Los comentarios pueden resultar básicos para entender qué está haciendo un determinado algoritmo.
Es algo bastante natural, sobre todo para los programadores con poca experiencia, el tener la creencia de que se van a acordar de lo que hací­a el algoritmo, por lo que bajo esa premisa el uso del comentario pierde sentido para ellos. A medida que la experiencia va llegando se llegan a nuevas conclusiones:
1) Como me he encontrado código que no he hecho yo y no está comentado no tengo ni idea de lo que hace. Además, el compañero que lo ha hecho o está a tope y no me lo puede contar o justamente se ha ido una semana de vacaciones. Mira tíº por donde esto tiene que estar arreglado esta misma mañana por lo que me voy a tener que quedar comiendo delante del ordenador, así­ que, la próxima vez que programe algo que no es para mi, lo comentaré, y le diré a mi compañero que haga lo mismo.
2) Estoy solventando una incidencia y recuerdo perfectamente que el código lo hice yo, pero miro y remiro lo que hace y no me acuerdo para nada de por qué tomé esta solución. Es más, no sé ni qué hace o para que sirve esto. Será mejor que comentemos los métodos al crearlos, incluidos los parámetros que se la pasan, así­ nos evitaremos estos problemas.
3) Mira qué bien, el método está comentado, sé lo que hace por lo que voy a arreglar la incidencia en un momento. El problema viene cuando resulta que alguien cambió el comportamiento del método y no actualizó el comentario, entonces me estoy creyendo que hace lo que dice el comentario… ¿os imagináis el resultado, no? … Está bien, además de añadir un comentario al crear el método, cuando lo modifique también lo ajustaré.
Por ejemplo, trabajando con C# el añadir comentarios a método es muy cómodo, íºnicamente pulsad tres veces “/” justo en la linea de encima de la definición del método y os aparecerá la estructura xml que tenéis en el método de abajo (sin rellenar claro, la tendréis que rellenar vosotros).
/// <summary>
/// Inserta un nuevo coche
/// </summary>
/// <param name=”codigoCoche”>Identifica de forma íºnica el coche</param>
/// <param name=”nombreCoche”>nombre del coche</param>
/// <param name=”numeroPuertas”>níºmero de puertas del coche</param>
/// <param name=”codigoMarca”>identifica de forma íºnica la marca del coche</param>
public void Insert(int codigoCoche, string nombreCoche, int numeroPuertas, int codigoMarca)
{
 // código necesario para la inserción
}
La buení­sima noticia al respecto es que ahora cuando utilicéis el Intellisense de Visual Studio, al seleccionar el método os aparecerán los comentarios que habéis puesto, algo que aumentará vuestra productividad.
Para llevar a cabo la misma acción con VB.NET en lugar de usar “/” tenéis que usar “‘” (comilla simple).
Otra buení­sima noticia es que existen herramientas que a partir de los comentarios que añadais a vuestros métodos, clases, interfaces, propiedades generan documentación automáticamente. Los famosos JavaDoc en java son un ejemplo, los archivos .chm para .NET lo mismo.
Saludos.
Miguel.

Buenas Prácticas: Uso de Regiones

Las regiones son otra herramienta que provee Visual Studio que ayuda a mantener el órden del código, aumentando así­ su mantenibilidad. Su principal caracterí­stica es que segíºn pulsas sobre la región esta se muestra o se oculta. Os describo por ejemplo las tí­picas regiones a usar en una clase.
public class Coche
{
#region Constantes
// codigo que define las constantes #endregion
#region Campos
// codigo que define los campos
#endregion
#region Propiedades
// codigo que define las propiedades
#endregion
#region Constructores
// codigo que define los constructores
#endregion
#region Métodos Píºblicos
// codigo que define los métodos píºblicos
#endregion
#region Métodos Protected
// codigo que define los métodos protected
#endregion
#region Métodos Private
// codigo que define los métodos private
#endregion
}
Si tenéis todas las clases estructuradas de la misma manera, encontraréis muy rápido las cosas. Además de que por supuesto la sensación de orden, el trabajar ordenado en sí­, es un valor muy importante y que aumentará la mantenibilidad.
Un saludo.
Miguel.

Definiendo Métodos Obsoletos (Deprecated)

Para los programadores que trabajáis bajo el soporte de un framework o de un conjunto de librerí­as de terceros os habréis encontrado en alguna ocasión que a la hora de utilizar alguno de los métodos que os brinda el conjunto de clases, alguno de ellos os lo indica como “Obsoleto” o “Deprecated”.
Los métodos obsoletos son aquellos que han caido en deshuso y que el responsable de desarrollo del framework quiere, por algíºn motivo (reubicación del método en otra clase, cambio del nombre del método, cambio de los parámetros, nuevos métodos más eficientes…), eliminar en futuras versiones. 
Normalmente un proveedor que pasa a indicar sus métodos como obsoletos lo suele hacer de alguna o varias de las siguientes formas:
1) Incorpora una descripción en la documentación indicando que el método está obsoleto y que en futuras versiones será eliminado.
2) A la hora de compilar la aplicación aparece una alerta (warning) indicando que el método está obsoleto. Nos avisa el compilador pero la aplicación sigue compilando.
3) Al utilizar el método obsoleto la aplicación directamente no compila.
Tras la teorí­a, unos ejemplos de cómo declarar métodos obsoletos con C#
Primero, cómo declarar una clase como obsoleta, dando warning recomendando usar otra clase en lugar de esta
[System.Obsolete(“usar clase ClaseNueva”)]
class ClaseAntigua
{
    public void Metodo() { }
}
Segundo, cómo declarar en la nueva clase un método obsoleto, dando error de compilación si se usa un método en concreto y recomendando el uso de un método alternativo
class ClaseNueva
{
    [System.Obsolete(“usar MetodoNuevo”, true)]
    public void MetodoViejo()  { }
    public void MetodoNuevo()  { }
}
Tercero, un ejemplo de uso de las clases
// Genera dos alertas
// (una por la instancia a la clase y otra por la llamada al constructor)
ClaseAntigua antigua = new ClaseAntigua();
// No genera ni errores ni alertas
ClaseNueva nueva = new ClaseNueva();
nueva.MetodoNuevo();
// Genera un error, terminando la compilación
nueva.MetodoViejo();
Saludos.
Miguel.

Buenas Prácticas: El Arte del Debug

Por temas laborales íºltimamente estoy teniendo contacto con proyectos donde participan un alto níºmero de programadores con poquita experiencia o chicos y chicas con una beca y que dan sus primeros pasos en este mundo recién acabada la carrera o con alguna asignatura aíºn pendiente.
La verdad es que aunque parezca contradictorio estoy aprendiendo muchí­simo de ellos, una cosa es que tengan poquita experiencia laboral y otra que no sepan de qué va esto y qué es lo que quieren. Está siendo una experiencia realmente gratificante.
Tras la puesta en situación me pongo ya con el tema principal del post que es sobre el debug. La verdad es que una de las cosas que estoy viendo al respecto de este perfil de profesional que antes comentaba, es que salen de sus carreras, modulos o estudios varios correspondientes sin que nadie les haya contado lo que es un debug, cosa que, sinceramente, no es que me sorprenda, es que me tiene realmente abrumado.
Por dios, no sabéis las horas y horas de resolución de errores, desesperos y cabreos que os váis evitar si ponéis en vuestra vida el  modeo debug de la aplicación que estáis desarrollando. Cualquier entorno de desarrollo medianamente decente, un Eclipse, NetBeans, Visual Studio, Delphi 2006, Zend Studio para PHP, incorpora dicho valor.
No lo dejéis de lado. Vuestra eficiencia se verá directamente afectada si no aprovecháis el recurso del debug.
Un saludo.
Miguel.

Buenas Prácticas: Uso de StringBuilder en lugar de concatenación

Hola a todos. 
Para los que no lo conozcáis, StringBuilder es una de las clases provistas por los framework de .NET y de Java. La finalidad de dicha clase es la de proveernos de una serie de herramientas que nos faciliten la concatenación de strings, ya no sólo en la mantenibilidad del código si no que también en cuanto a la eficiencia en rendimiento.
El uso es muy simple (código C#):
StringBuilder builder = new StringBuilder();
builder.Append(“hola”);
builder.Append(“qué”);
builder.Append(“tal”);
builder.Append(“estás”);
En lugar de:
String builder = String.Empty;
builder += “hola”;
builder += “qué”;
builder += “tal”;
builder += “estás”;
Además, disponemos de una serie de métodos más que nos facilitan un poco la vida, pero insisto que el valor más importante es el de la mejora de rendimiento.
Saludos.
Miguel.

Buenas Prácticas: Los servicios web no deberí­an devolver tipos especí­ficos de la tecnologí­a

Tí­pico ejemplo de esta situación es un servicio web hecho en .NET que devuelve un Dataset.
Si se nos garantiza que el consumidor del servicio va a ser siempre un cliente .NET aíºn la cosa se sostiene un poco. El problema es si por ejemplo intentamos consumir un servicio que da un Dataset por otra tecnologí­a que no es .NET.
Para los que tengáis experiencia trabajando con servicios sabréis que una vez que creas un servicio que devuelve un objeto o tiene por parámetro un objeto definido en el servicio, desde el cliente que consume el servicio tenemos visibilidad sobre la definición de dicho objeto. Si yo tengo un servicio que recibe por parámetro un objeto coche, yo desde el cliente puedo rellenar dicho objeto coche y pasárselo por parámetro al servicio. Lo mismo ocurre si el coche me lo devuelve el servicio, yo puedo conocer sus propiedades y extraer los valores de las mismas.
¿Pero qué ocurre con un dataset? ¿Ocurre lo mismo? Pues no.
El principal problema de un Dataset es que en tiempo de diseño no conocemos cuál es su contenido. Sólo lo sabemos en tiempo de ejecución. Ya “sólo” por este “pequeño” problema tenemos ya un agujero del tamaño de un tonel respecto a la protección de tipos en tiempo de diseño. Podemos pedirle lo que quiera al dataset, porque el compilador no va a darnos ningíºn tipo de alarma, nos vamos a enterar en tiempo de ejecución generando una excepción si la consulta sobre el dataset no era correcta.
Este problema se vuelve más complicado aíºn si consumimos el servicio desde por ejemplo un cliente java, ya que para interpretar el contenido del dataset en tiempo de ejecución no nos va a quedar más remedio que leer el mensaje xml que nos llega con el contenido, leerlo e interpretarlo a pelo.
¿Cual es entonces mi recomendación? No es difí­cil respuesta adivinarlo si leéis los artí­culos de esta web, por mi parte está claro, Data Transfers Objects 🙂 O Value Objects, que es lo mismo 🙂
Saludos!
Miguel.

Buenas Prácticas: Encapsular, encapsular y encapsular.

Quisiera poner un ejemplo bastante gráfico para dejar patente la importancia de la encapsulación. Es muy bonito el concepto de encapsulación, todos lo conocemos y lo utilizamos, pero seguramente no todas las veces que deberí­amos. Inicio el ejemplo:
Tenemos un objeto que controla cual es el tabulador activo en una tí­pica ventana con pestañas, como esta. Hemos encapsulado nuestro objeto y le hemos creado un método píºblico que se encarga que desde fuera del objeto poder elegir cual es la pestaña activa.
Algo así­ como: (código C#)
ObjetoTabulador tab = new ObjetoTabulador();
tab.SetPestaña(3); // 3 es el níºmero de la pestaña que vamos a activar
Vale, está claro que esto funciona, pero no está bien encapsulado. Diseñando este objeto así­ estamos dando por hecho que sabemos lo que hace por dentro el ObjetoTabulador. Si yo quiero activar la tercera pestaña le paso un 3 y ese es el dato que se utiliza internamente.
¿No creéis que serí­a mejor solución la siguiente?
ObjetoTabulador tab = new ObjetoTabulador();
tab.SetPestaña(ObjetoTabulador.Pestañas.Informes); // informes corresponde a la pestaña de informes en el tabulador de la imagen
¿Qué ha cambiado aquí­? Pues que en lugar de pasarle el níºmero le estamos pasando un tipo enumerado que aporta el mismo ObjetoTabulador y es el que internamente va a tratar cual es la pestaña a activar. ¿Quién dice que mañana la pestaña de Informes va a seguir en la tercera posición? Si esto cambiara todas las llamadas que activan el tabulador por níºmero pasarí­an a ser inconsistentes, mientras que pasándole el tipo enumerado seguirí­a activándose la pestaña que le habí­amos indicado. Por cierto, pasándole un í­ndice estamos dejando al descubierto que internamente estamos gestionando las pestañas con una lista.
Este error viene dado muchas veces porque cuando estamos tratando con objetos que nosotros mismos creamos y a los cuales tenemos acceso directo a partir de nuestra propia aplicación nos acostumbramos a que sabemos lo que hacen internamente y lo podemos cambiar. No resulta esta la mejor manera de programar, a la hora de desarrollar hay que pensar siempre en que los componentes que hacemos han de poder funcionar de forma totalmente independiente y que no debemos necesitar mirar su código interno para saber qué es lo que hacen.
Si con un objeto tan tonto como un control de tabulación la mejora es tan grande, (recuerdo que hemos evitado los errores que se generarí­an al modificar el orden de las pestañas, hemos elevado la mantenibilidad del código y la productividad del desarrollo), doy por hecho que os hacéis a la idea de lo que supondrí­a tener en cuenta estas cosas al trabajar con objetos más complicados.
Es curioso porque cuando desarrollamos DLL’s de componentes o de objetos el concepto de encapsulación lo tenemos más claro, pero cuando utilizamos objetos propios de los cuales tenemos acceso al código fuente, se nos olvida lo de la encapsulación.
No hay que dar por hecho que para entender lo que hace una clase hay que mirar su código.
Saludos.
Miguel.

Buenas Prácticas: Agrupando Clases por paquetes/namespaces/grupos de clases

Siguiendo con las buenas prácticas hoy vamos a hablar de una que tiene que ver con la organización del proyecto, en concreto en la forma en que organizamos las clases, enumeradores e interfaces que lo forman.
Para empezar, os dejo aquí­ una captura de una aplicación la cual tiene todos sus compenentes sin ningíºn tipo de organización.
Sin Agrupación
Esta forma de organizarse en principio en un proyecto pequeño puede llegar a ser sostenible, el problema viene cuando la cosa empieza a crecer y a crecer. Cuando esto ocurre la gestión de dichas clases se complica, encontrarlas por ejemplo puede hacerse complicado. Si necesito trabajar con un determinado Enumerador, tal vez me ayudarí­a el saber que los enumeradores los tengo encapsulados en un grupo (paquete, espacio de nombres…)… o tal vez si tengo definido una clase para acceder a un GPS, me ayudarí­a a encontrarla el saber que se encuentra contenida en un grupo donde se catalogan todas las clases de acceso a dispositivos externos.
Imagináos por ejemplo, los que conozcáis el framework de Java o el de .NET, si las clases en lugar de estar agrupadas en paquetes o en espacios de nombres, estuvieran todas sueltas. Nos volverí­amos locos. Por eso insisto en el hecho de que aplicar esta misma organización en nuestros propios proyectos, ya no sólo mejorá en encontrar más rápido las cosas, si no que además en el hecho de que mantener nuestro proyecto organizado (en todos los sentidos) va a decir mucho de nosotros, sobre todo si el código va a pasar a ser mantenido o auditado por otros grupos de trabajo (incluso por tus propios clientes). No sólo hay que ser un buen profesional, si no que también hay que parecerlo.
Os dejo ahora una captura con las clases anteriores pero organizadas en paquetes.
Agrupando en Paquetes
Y finalmente, la agrupación, pero desplegada para que veáis qué se ha metido en cada paquete.
Agrupado en paquetes y desplegado
Otro tema a parte es cómo jerarquizar los paquetes, eso ya os lo dejo a vosotros porque va a depender de vuestra forma de trabajar o tal vez del proyecto e incluso de vuestra empresa. Con suerte tendréis estipulado cual es la jerarquí­a básica para vuestros proyectos y partiréis de ella.
Un saludo.
Miguel.

Buenas Prácticas: Legibilidad y Mantenibilidad del Código

Y es que muchas veces nos olvidamos de que nuestro código va a tener que ser interpretado, leí­do y mantenido por otras personas, o incluso por nosotros mismos en un futuro.
Mantener estructuras similares a la hora de programar, un estilo de programación, un orden determinado y un código claro, harán que la mantenibilidad de nuestras aplicaciones se dispare. Este aspecto se ve aíºn más potenciado en grupos de trabajo de alta volatilidad, donde la estabilidad del níºmero de profesionales que forman el grupo es alta. Me refiero tanto a la baja de miembros del equipo como a la rápida incorporación de nuevos profesionales para aumentar el tamaño del grupo.
Quisiera dejar patente la diferencia de legibilidad y mantenibilidad entre dos fragmentos de código que llevan a cabo exactamente la misma funcionalidad
Ejemplo de baja legibilidad y mantenibilidad (código C#):
public bool NumPuerMayorQue(int t)
{
    int n = 0;
    coche[] lista = DameListaCoches();
    for(int i=0;i<lista.lenght;i++)
        n = n + (coche)lista[i].NumPuertas;
    if (n>t)
        return true;
    else
        return false;
}
Ejemplo de mejor legibilidad y mantenibilidad
/// <summary>
/// Añade un nuevo parámetro a la lista
/// </summary>
/// <param name=”numPuertas”>Níºmero de puertas a comparar</param>
/// <param name=”lista”>Lista genérica de coches sobre la que hacer el cálculo</param>
/// <returns>Retorna verdadero en el caso de que la variable numPuertas pasada por parámetro sea mayor que el resultado de sumar todas las puertas de los coches pasados por parámetro en la variable lista. Retorna falso en caso contrario, es decir cuando es menor o igual.</returns>
public bool IsNumeroPuertasMayorQue(int numPuertas, List<coche> lista)
{
    int total = 0;
    foreach (coche unCoche in lista)
    {
        total += unCoche.NumPuertas;
    }
    return (total > numPuertas);
}
Aspectos que hacen notar la mejora de la mantenibilidad y la legibilidad de ambas funciones
1) Se dispone de un comentario sobre qué labor va a realizar la función, qué papel juega cada uno de sus parámetros y qué valores se esperan retornar y en qué condiciones.
2) El nombre de la función, al marcar el prefijo “Is” ya nos da la pista de que va a devolvernos un booleano. IsNumeroPuertasMayorQue da más pistas al desarrollador que NumPuerMayorQue.
3) La lista de coches es pasada por parámetro a la función, siendo además una lista genérica. Sabemos exactamente de dónde nos llega la lista.
4) Uso de foreach en lugar de for. Usando foreach aumentamos la legibilidad y la elegancia de nuestro código.
5) Uso de lista genérica en lugar de arrays. Nos estamos evitando hacer el cast “(coche)lista[i]”, que además no nos asegura que lo que realmente tenga la lista sean objetos de tipo coche, puede darse un error de casting.
6) El nombre de las variables utilizadas es mucho más descriptivo.
7) Llaves en sentencias de una sóla lí­nea. Realmente funcionan igual, pero si a las sentencias for, foreach, if y else le añadimos llaves de apertura y cierre aunque incluyan una íºnica sentencia, lo leeremos mejor.
8) Creo que queda bastante claro que se lee mejor “return (total > numPuertas)”
9) Una linea en blanco entre bloques. ¿La vista lo agradece, no?
Saludos.
Miguel.