Busqueda local

Loading

jueves, 25 de noviembre de 2010

Principios de diseño

Para el programador novato y el experto que no ha tenido el cuidado de aprender sobre el tema, este puede ser un punto de partida. Para mi aprender el patrón MVC de ASP.NET, significo un renacer a la programación web.
Durante mucho tiempo estuve inmerso y acostumbrado a que las aplicaciones web debían ser complicadas, cuando descubrí que uno de los pilares de este nuevo modelo era la idea de que debe ser simple, desde luego que capto mi atención.

El principio KISS (keep it simple stupid) con sus siglas en ingles, nos invita a evitar la complejidad innecesaria. En pocas palabras: “Fácil de explicar, fácil de entender”.
Hoy en día es una realidad que los programadores no estaña acostumbrados a a dividir la aplicación en componentes lo suficientemente pequeños para que sean entendidos y explicados con facilidad.
Desde luego es cuestión de la personalidad de cada quien, los que somos del área técnica no somos muy humildes que digamos, así que lo primero que debemos aprender es a ser humildes. Antes de que empecemos a codificar debemos tener la solución, no tratemos de solucionarlo sobre la marcha, es una mala costumbre.

El principio DRY (dont replay yourself) con sus siglas en ingles, toca otro punto sensible en la comunidad de desarrollo: Cada pieza de código debe ser única en todo el sistema, así tenemos un solo punto donde darle mantenimiento. Es muy fácil comprender por qué resulta un problema cuando el código esta duplicado. Si tenemos que hacer algún cambio o adaptación, la complejidad incrementa exponencialmente.

Y si ya lo hice mal, que puedo hacer?

Los programadores tenemos miedo de cambiar la idea original, sobre todo si vemos que el código no tiene errores. Pero el que no tenga errores, no quiere decir que este correcto, no?
Entonces qué debo hacer: Refactorizar!!!.

Refactorizar es modificar el código fuente sin cambiar su comportamiento. Es una práctica que pocos llevamos a cabo, pero que es muy valiosa si trabajamos en equipos de desarrollo. Podemos decir que refactorizar es como hacer la limpieza de la casa, cuando van a llegar visitas, levantamos, barremos, y ponemos las cosas en su lugar.

Esto puede ser considerado una especie de mantenimiento cuyo objetivo no es reparar algún error, o agregar alguna funcionalidad a la aplicación. La idea es otra, se trata de organizar el código para que sea más fácil de entender, durante esta labor casi siempre podemos identificar código muerto u obsoleto.
Cuando codificamos para nosotros mismos podemos caer fácilmente en uno de los errores mas ocultos en nuestro código: El Acoplamiento.

Nuestro código puede ser de dos tipos: Fuertemente cohesivo o permisivo. A esto se le conoce como Acoplamiento, el primero es cuando una clase depende de otra, y se puede dar por la herencia, pero también se puede dar por que conocemos el interior de dicha clase y al programar cometemos el error de que dicho conocimiento lo consideramos inconscientemente como parte del código de la otra clase. Es en este momento que creamos una dependencia no natural entre ambas clases.
El segundo, como su nombre lo indica es permisivo, o sea la relación entre las clases no es dependiente, esto es posible por medio del uso de interfaces, o del encapsulamiento adecuado de la implementación de cada clase, a pesar que nosotros mismos estemos codificando ambas.
Otro principio que descuidamos es la Cohesión. Cuando estamos codificando cometemos el error estratégico de poner en la misma clase métodos que tienen muy poco en común entre si. Incluso es probable que tengamos como costumbre crear una clase de “utilerías” donde colocamos métodos que sirven para actividades diferentes, por ejemplo acceder a la cadena de conexión o abrir un archivo xml, y todo por que el código parece ser similar.
Al principio no parece ser un problema real, pero si nos detenemos a pensar un poco, podemos darnos cuenta en qué momento nos va a afectar. Por ejemplo si tratamos de reutilizar la biblioteca, hay mucho código que no le sirve a la nueva aplicación. Por lo que la estamos condenando a cargar un lastre innecesario.

Para este tipo de problema hay varios niveles o grados:
  1. Coincidencia: Funciones de uso frecuente.
  2. Lógica: Rutinas que son similares.
  3. Temporal: Funciones que atienden una situación de momento.
  4. Procedural: Funciones que se complementan.
  5. Comunicación: Mismo tipo de datos.
  6. Secuencial: Funciones que llaman a otras.
  7. Funcional: Contribuyen a una tarea
El reto para nosotros es tenerlos en cuanta al momento de codificar, partiendo de la premisa que mientras, mas lejos estemos del 1, es mejor para nuestro código.
De todos los principios que aquí comento este es el que más gracia me causa por su nombre: Ingenuidad. Así es los programadores somos ingenuos con mucha facilidad. Por ejemplo, podemos creer que es fácil adaptar una pieza de código que fue concebida para hacer algo completamente diferente. Muchos creen que se ahorran tiempo si copian y pegan código. Creemos que no necesitaos hacer análisis y diseño, creemos que por nuestra experiencia no necesitamos ni un solo diagrama. Y el peor de todos, creemos que podemos ser innovadores por nuestra cuenta, cuando estamos trabajando en un equipo de desarrollo, sin que esto afecte al proyecto.

Como podemos ver estos principios deben ser observados y considerados cuando trabajamos, ASP.NET MVC fue diseñado pensando en todo esto, una vez que conocemos el modelo podemos darnos cuenta como nos ayuda a seguir patrones y principios de diseño, buenas prácticas de desarrollo, estándares, etc.
En futuros post hablare de patrones de desarrollo.

No hay comentarios:

Publicar un comentario