20. Métricas (Indice de Mantenibilidad)

Tengo varios temas que retomar con ustedes, temas que he dejado en este blog, pero que continuare escribiendo sobre estos, principalmente los patrones de diseño y el análisis de queries, ambos parte fundamental en el proceso de desarrollo.

Como he comentado en otros Post, Visual Studio, nos proporciona herramientas para poder medir el código, para darle una valoración al mismo, esto es importante ya que el código debe ser sencillo de entender por más de un desarrollador, es decir debe poder dársele mantenimiento de una manera sencilla.

Mientras más especializados son los componentes son más fáciles de controlar, estos se convierten en piezas esenciales de algo más grande.

Hoy vamos a hablar de la última métrica, que se encuentra en Visual Studio, el índice de mantenimiento, ¿Por qué la deje al último? Porque esta es la más sencilla, su nombre nos dice por si sola que es, esta nos dice que tan fácil es modificar  nuestro código, y mejor aún, nos lo indica con una bandera que va de rojo a verde.

Mientras el valor se encuentre más cercano al 100 es mejor, pero entonces me dirá, un índice de mantenimiento de 59 es bueno, la respuesta es sí, para el caso de .NET, como lo veremos a continuación.

Se puede decir que es un resumen de las otras métricas, el índice de mantenimiento  es una métrica creada allá por 1992 por Pau Oman y Jack Hagermeister, esta métrica agrupa varias otras como son el Volumen de Halstead (HV) esta es la única métrica que no hemos tocado en esta serie de post esta se define como el número de operaciones por el logaritmo base dos de operaciones distintas (N log2 n) , la complejidad ciclomatica (CC), las líneas de código (LOC) y la cantidad de comentarios.

Con estos valores se propuso una fórmula que nos da que tan mantenible es el código, la formula propuesta fue:

171-25ln(HV) – 0.23CC – 16.2ln(LOC) + 50.0Sin sqr(2.46*COM)

El paper original se encuentra en esta liga: ColemanPaper.pdf

Visual Studio no implementa en su totalidad esta fórmula, Visual Studio implementa una versión reducida de la misma, esta es:

Indice de Mantenibilidad = MAX(0,171-5.2 * ln(HV) – 0.23(CC) – 16.2*ln(LOC) * 100/171

Como se puede ver el equipo de Visual Studio elimino la parte que corresponde a los comentarios en el código.

Microsoft toma en cuenta estos rangos para limitar la mantenibilidad del código

El índice de mantenimiento cambia a amarillo entre 10 y 19 y a rojo ente 0 y 9, pero que es realmente el índice de mantenimiento.

0 – 9 Índice pobre

10 – 19 Índice Moderado

20 – 100 Índice Alto

Codificar no es solo colocar una instrucción tras otra, es necesario que seamos constructores de código de calidad, para reducir el esfuerzo de construcción, mejorar la calidad, disminuir los errores, mejorar el rendimiento, y lo más importante reducir el stress que se genera por códigos con problemas, que al final repercuten en la salud del desarrollador

Felices líneas

19. Métricas (Numero de lineas)

Número de líneas, esta es una de las métricas clásicas, incluso durante mucho tiempo se medían los programas por la cantidad de líneas de código que hubiera en ellos.

¿Pero que tan útil es?

Cuando hablamos de un desarrollo una operación puede ser por pocas o por muchas líneas de código dependiendo del desarrollador, por lo que una complejidad real de la solución no nos la puede dar.

Medir el trabajo en líneas de código no es una buena idea.

Sin embargo si nos ayuda en algo, nos ayuda a ver que métodos y funciones poseen gran tamaño, cuando un método es de un tamaño elevado, este se vuelve muy complejo, empieza a tener una responsabilidad muy alta, como consecuencia es más difícil de manipular.

Tradicionalmente se ha dicho que un método debe ocupar únicamente el espacio de la pantalla del equipo para ser correcto, esta observación no es del todo correcta, un método debe ser un ente altamente especializado, encargado de una actividad, esto muchas veces se puede lograr con muchas o con pocas líneas de código, el hecho de que un método tenga muchas líneas de código no necesariamente dice que está mal, o el hecho de tener muchos métodos muy pequeños con muy pocas líneas nos dice que es lo mejor. Hay que analizar cada caso, ver en que las operaciones se encuentren agrupadas, si bien divide y vencerás debe ser nuestra política, una división muy alta puede provocar que la complejidad se incremente.

Un método puede tener muchas líneas de código (no es lo deseable) pero si esto es justificado, es correcto.

Felices lineas

18. Métricas (profundidad de herencia)

Continuemos con las métricas que nos proporciona Visual Studio, la siguiente métrica, es útil porque nos ayuda a saber que tan complejo es un código.

Pero antes necesitamos un poco de teoría básica, para determinar que es la herencia, bueno la herencia es una de las principales características de la programación Orientada a Objetos, la herencia nos permita que un objeto sea creado a partir de otro, de esta forma el nuevo objeto toma los métodos y atributos que tenía el original.

Esto nos permite agregar funcionalidad sin reescribir todo el código, por lo que la reutilización del mismo es muy alta.

Bueno que nos indica la métrica de profundidad de la herencia nos indicia que tan grande es este árbol de herencia hasta llegar a la clase base.

¿Por qué nos afecta esto?, si bien el código se puede reutilizar, manejar clases con herencia de la herencia como se diría coloquialmente, hace que los flujos se vuelvan complejos, para seguir un flujo se deben hacer muchos saltos entre las clases ¿Quién la heredo? ¿Quién la modifico la primera vez? ¿Quién lo hizo la segunda vez? Y así sucesivamente.

El resultado el código se torna complejo, y entre mayor sea este número el código se vuelve más difícil de entender.

Manejar este número en valores menores 4 es lo mejor siempre.

Sin embrago no hay que asustarse si este número es alto, muchas características de código autogenerado de Visual Studio, nacen con este número en valores mayores a 4, así que analicen en que caso es su código y en qué caso es Visual Studio el que genero este número.

Y como la obtengo, siguiendo el mismo procedimiento que hemos discutido en artículos anteriores.

Las métricas son útiles porque nos ayudan a tener un mejor código, hasta la próxima.

Saludos

16. Metricas (Cohesión y Acoplamiento)

Cuántas veces hemos escuchado, un buen diseño tiene alta cohesión y bajo acoplamiento, en cuantos documentos hemos leído… una de las características de este diseño es su alta cohesión.

¿Qué es eso?

Ambas son características de la programación orientada a objetos características que son muy importantes durante la etapa de diseño que pueden ser definidas de la siguiente forma:

Cohesión: Lo podemos entender como que cada uno de nuestros módulos sea altamente especializado en sus características o componentes, dicho en un lenguaje más coloquial, hablar siempre del mismo tema, esto nos facilita el diseño, la programación, las pruebas y el mantenimiento, así mientras mayor sea la cohesión mejor es el resultado en el sistema.

Sin embargo este es un concepto abstracto, que no puede ser fácilmente evaluado por una máquina, para determinar el grado de cohesión de un sistema es necesario validar el diseño, y ver que cada módulo sea un módulo especializado.

Y que pasa con el acoplamiento, bueno este es el grado en que una clase conoce a otras, las clases no son independientes, pese a que se recomienda un acoplamiento bajo, las clases requieren conocer a otras, este grado de conocimiento entre las clases genera el acoplamiento, de tal forma que una clase con alto acoplamiento tiene acceso a muchos métodos de diferentes clases, como consecuencia la clase es más compleja, y esta complejidad es la que debemos cuidar cuando tenemos un acoplamiento muy alto.

Mientras más compleja sea una clase, más difícil será el mantenimiento, mayor cantidad y complejidad de pruebas tendrá y será más propensa a errores.

Pero también hay que considerar algo, clases sin acoplamiento no son útiles, porque ningún ente vive aislado en este mundo.

A diferencia de la coherencia, para el acoplamiento, Visual Studio si nos permite obtener por medio de una herramienta el acoplamiento, para ello debemos ir al menú analizar y solicitar las métricas de la solución.

 “Calcular métricas de código para la solución”

Visual Studio inicia con la compilación del código y posteriormente, obtenemos los resultados.

¿Qué valor es óptimo? Este número siempre se debe encontrar en un valor inferior a 9, que incluso puede ser validado por medio de la herramienta de Code análisis de Visual Studio.

Hasta pronto

14. Calidad

Y el reloj avanza sin parar y ya es hora de entregar esa nueva versión del nuevo producto, el programa todavía no se encuentra listo, los minutos corren, los equipos de trabajo se encuentran produciendo líneas de código bajo presión, se empiezan a eliminar características deseables o no esenciales, se hace la entrega y resulta que los programadores tienen mucha ceguera de taller y hay más errores de los que esperábamos, los flujos que se probaron y se diseñaron son muy estrictos, tan así que el menor cambio hace que la aplicación falle.

La entrega al cliente es mala o se retrasa, se genera insatisfacción y además el esfuerzo extra de las últimas horas quemo a el equipo de trabajo, la cantidad de errores excesivos, hace que muchos pierdan la paciencia.

Y acabamos de perder un proyecto que pudo haber sido el proyecto mejor planeado.

Dentro de este mundo del código salvaje quiero platicar un mal habito que tenemos casi todos los programadores, una frase muy común llamada “trabajo mejor bajo presión”, que no es más que la justificación de “Se acabó el tiempo y tengo que codificar muy rápido”.

¿Realmente se acabó el tiempo?

Cuando nos encontramos del lado de la programación tenemos la tendencia a perdernos en un mar de líneas de código pensando en flujos y pensando que el tiempo siempre alcanza. Perdiendo muchas veces día a día productividad desviándonos en actividades fuera del producto original, al final ese esfuerzo extra tan común en el final de un proyecto se puede dar sin pensarlo.

¿Pero qué tan conveniente es? La respuesta es nada, no es conveniente, como humanos al estar cansados nuestra mente no reacciona igual comete más errores.

Es importante que todo el equipo sepa cómo se encuentra el estado de un proyecto, para poder hacer correcciones a tiempo, las correcciones no es trabajar más, la corrección es como encontrar la manera de dedicar el tiempo adecuado a cada actividad.

Un proyecto que se encuentre con errores tiene un costo mucho mayor a una entrega fuera de tiempo, ya que genera una mayor insatisfacción, puede ser hasta peligroso porque un flujo no probado puede causar que un sistema pierda información valiosa.

Nosotros somos los guardianes de la información, eso es para nosotros lo más importante, si la información se daña, perdemos realmente el fin por el que estamos aquí.

La imagen de la empresa, la imagen de nosotros mismos, se daña más con un producto de mala calidad, que con un producto en el que se habló a tiempo el estado del mismo y se aplicaron las medidas para que el producto sea satisfactorio para el cliente.

Terminar un proyecto no es entregar un código.

Terminar un proyecto es que el usuario se sienta bien con el programa, que lo sienta una extensión de él, y que cumpla una de las características más importantes por las que estamos aquí, simplificar las cosas hacer que el sistema sea tan sencillo que realmente permita al usuario dedicar su tiempo en otras actividades.

Un sistema debe ser de tal forma que un usuario debe saber que existe, usarlo pero sin que esto represente que se convierta en un dolor de cabeza.

Las nuevas generaciones no leen manuales, eso lo tenemos que tener en cuenta, por eso cada flujo debe ser confiable, fácil de entender y agradable en su hacer.

Saludos

13. Plan de ejecución (I)

Como desarrolladores muchas veces perdemos la visión, sentimos que el código lo es todo y que todo lo que no es código va más allá de nuestras funciones.

¿Por qué digo esto?

Por un tema llamado base de datos, muchas veces como desarrolladores pensamos que el sistema es todo aquello que no es la base de datos, lo cual es un error, ya que nosotros nos dedicamos a procesar, a interpretar y a darle un valor a la información.

En cualquiera que sea nuestra área, siempre estamos trabajando con la información, por ello no debemos perder el contexto de la base de datos.

Tenemos un gran defecto, que se ve sobre todo en desarrolladores novatos, confiamos demasiado en la velocidad de los sistemas actuales, y poco en si el código que estamos empleando es el mejor para el caso en el que nos encontramos.

A este punto es al que me trae el artículo del día de hoy.

¿Si es un blog de desarrollo, por que analizar los Queries?, bueno porque al final si la base de datos no se comporta de la mejor manera, el sistema que estamos desarrollando no reunirá las expectativas para un cliente.

La herramienta que usaremos para ver esto, son los planes de ejecución. ¿Qué es un plan de ejecución?, es una herramienta que nos proporciona SQL Management Studio para comprender den forma gráfica (en realidad es un XML) que es lo que hace un Query que se ejecuta en la base de datos para que nosotros obtengamos un resultado en específico.

Desde un plan de ejecución, nosotros podemos ver ¿Qué elemento consume un mayor tiempo de procesador?, verificar si requerimos algún cambio a la estructura de la base de datos (índices, claves primarias, foráneas) o simplemente comparar cual de 2 queries es el mejor para resolver una situación.

¿Cómo lo generamos?

Generar un plan de ejecución es muy sencillo, lo único que debemos hacer es entrar a SQL Management Studio y escribir el query que queremos tomar.

Ahora bien tenemos 2 tipos de plan de ejecución el estimado, que se presenta antes de la ejecución del Query, y el Real.

Mi recomendación es que siempre trabajemos con el real, este se muestra una vez que el query termino su ejecución y nos muestra que es lo que realmente hizo la base de datos.

Bien, creemos un ejemplo de un plan de ejecución:

Paso 1: Escribamos un pequeño query

Paso 2: Activemos el plan de ejecución, para eso es necesario ir a menú consultas (query) y activar la opción Desplegar plan de ejecución Real (Include Actual Execution Plan)

Paso 3 Ejecutemos el Query

Al ejecutarlo nos aparece una nueva pestaña

Que muestra el plan de ejecución

Ahora falta analizarlo lo cual será el tema del próximo artículo, hasta pronto

12. Patrones de Diseño (III) - Facade

La programación salvaje es como una enredadera si no tenemos cuidado en muy poco tiempo se mete en todo nuestro proceso complicando cada día más su mantenimiento.

También se puede decir que es como una hidra, que crece y se convierte en un ser de muchas cabezas.

Como programadores no siempre es posible conocer la funcionalidad de todos los módulos, lo mejor siempre es tener módulos especializados y rehusarlos cuando esto sea necesario, pero existe un gran problema en esto, las muchas cabezas que puede tener un módulo y que debemos evitar, es aquí en donde nos ayuda el patrón de diseño del que hablaremos el día de hoy, el patrón Facade, o Fachada, es un patrón estructural que nos ayuda a dar visibilidad del código.

El patrón indica que se debe tener una sola clase de entrada sin importar la complejidad del código que se encuentre en la aplicación.

El patrón ordena el código de tal forma que cuando se emplea el modulo, pese a lo complejo de su interior, solo tendrá un punto por el que toda la funcionalidad sea accedida.

Este es un patrón muy útil, y realmente muy fácil de implementar que nos va a quitar muchos dolores de cabeza en el código.

Bueno siguiendo la lógica de que un programador busca menos teoría y más código, pongamos un ejemplo del uso de este patrón.

Nuevamente tomando el ejemplo de un carro, yo tengo una clase radio, la clase radio se muestra de la siguiente forma:

Como podemos ver el tablero de control en el que el usuario del carro controla el radio es nuestra clase fachada, y esta clase dispara procesos hacia adentro del radio, estos procesos cambian la estación, suben el volumen, controlan la reproducción de MP3, sin saber qué es lo que ocurre más atrás.

Ahora veamos qué pasa si esta clase creada en el punto anterior interactúa con un usuario, que en este caso es un programa que consume el servicio que se encuentra implementado bajo este patrón de diseño.

Resultado, solo un espacio de nombres, el código está estructurado y es más fácil de implementar.

Un paso más para evitar la programación salvaje, saludos

9. Patrones (II) - Decorator

El código salvaje crece de una manera incontrolada, esto hace que en muchos casos se pierda el control del mismo, y en casos extremos se tengan que hacer completos proyectos que si bien en su fase de diseño fueron muy buenos, con una arquitectura estable, conforme se van agregando nuevas funcionalidades y más desarrolladores modifican el código, estos se convierten en verdaderos monstros de Frankenstein.

Muchas piezas de código operando para crear nuevas funcionalidades, y en ciertas ocasiones por no conocer el sistema, estas hacen que el sistema sea inestable.

El tiempo de desarrollo se incrementa, la calidad baja, y de la misma forma baja la satisfacción del cliente.

Pero, ¿Hay alguna forma de modificar funcionalidad que sea no tan dolorosa?

Vamos a platicar de un patrón de diseño que es para esto, su nombre es Decorator, y se emplea para añadir de manera dinámica funcionalidad a un objeto, de esta forma podemos incrementar las características del objeto, sin que esto nos represente un cambio doloroso.

Eso si hay que cambiar un poco nuestra mentalidad para usarlo, y pensar más en términos del patrón

Su principal característica, es que nos permite agregar de manera incremental responsabilidades, el patrón lo aplicamos como si fueran capas y las capas nos brindan nuevas características, imaginemos que es una perla que se está creando y cada capa es una aplicación del patrón.

Este es un patrón estructural y lo podemos usar durante el diseño, mantenimiento o extensión de funcionalidad.

Podemos representar el patrón de la siguiente forma

Sin embargo creo que esto lo podemos ilustrar mejor con un poco de código.

Imaginemos esto somos una fábrica de carros, y vamos y vamos a ponerle el radio a uno de nuestros carros, así que crearemos una interfaz en la cual se encontrara el método encender radio

namespace decorator01

{

    public interface ICarro

    {

        void EncenderRadio();

    }

}

El radio lo vamos a implementar en nuestro modelo básico

public class CarroEstandar : ICarro

    {

        public void EncenderRadio()

        {

            Console.WriteLine("Radio FM - Mono");

        }

    }

Como se puede ver el modelo básico cuenta con un Radio FM con sonido mono aural, bueno viene un nuevo modelo, en el cual se requieren mejoras a este radio, así que tomamos el modelo básico y lo mejoramos

  public class CarroMejorado : ICarro

    {

        ICarro CarroBase;

        public CarroMejorado (ICarro I)

        {

            CarroBase = I;

        }

   

        public void EncenderRadio()

        {

            CarroBase.EncenderRadio();

            Console.WriteLine("Radio Satelital");

        }

}

Ahora el radio cuenta con una nueva función, sin perder la primera, si tuviéramos otro modelo, podemos crearlo ahora partiendo de cualquiera de los modelos anteriores.

public class CarroBlindado : ICarro

    {

        ICarro CarroBase;

        public Boolean DobleBlindado { get; set; }

        public CarroBlindado(ICarro I)

        {

            CarroBase = I;

        }

        public void EncenderRadio()

        {

            CarroBase.EncenderRadio();

            if (DobleBlindado == true)

            {

                Console.WriteLine("Audio Alta calidad");

            }

            else

            {

                Console.WriteLine("Audio Especial");

            }

        }

    }

Construyamos ahora nuestros carros:

class Program

    {

        static void Main(string[] args)

        {

            Console.WriteLine("Construyendo carro estandar");

            CarroEstandar cr1 = new CarroEstandar();

            cr1.EncenderRadio();

            Console.WriteLine("Construyendo carro Mejorado");

            CarroMejorado cr2 = new CarroMejorado(cr1);

            cr2.EncenderRadio();

            Console.WriteLine("Construyendo carro blindado");

            CarroBlindado cr3 = new CarroBlindado(cr2);

            cr3.DobleBlindado = true;

            cr3.EncenderRadio();

            Console.ReadLine();

        }

Al iniciar la producción vemos lo siguiente

Como podemos observar se puede agregar funcionalidad de manera dinámica de una forma mucho más libre que empleando la herencia

Di no al código salvaje

7. Programar en paralelo (I)

A partir de .Net 4.0 llego a su madures la programación en paralelo por .net, la posibilidad de efectuar múltiples operaciones en forma simultánea con la finalidad de reducir tiempos, y emplear mejor los recursos de sistema.

El nuevo modelo nos permite emplear de forma simultanea los núcleos del procesador, anteriormente se requería un manejo a un nivel más bajo para lograr que las tareas se distribuyeran en forma paralela, hoy esto no es necesario.

Pero antes de considerar el uso de las funciones de .Net para programar en paralelo tenemos que hacer unas consideraciones.

¿Cuáles serán los recursos en los que se empleara la programación en paralelo?

Al emplear este tipo de programación se debe considerar que si el recurso no soporta cierta cantidad de peticiones, el rendimiento en vez de incrementarse puede verse afectado, esto es por ejemplo mandar un gran número de peticiones a una base de datos, o escritura a un disco.

¿Realmente será perceptible el cambio?

Si la cantidad de peticiones es tal que al emplear este tipo de programación se vea un cambio perceptible en el rendimiento, hay que usarla, pero si el cambio no es perceptible, no es conveniente incrementar la complejidad del código.

Bueno y como se emplea, el modelo más sencillo de programación en paralelo es la invocación de más de una función en el mismo instante de tiempo.

Para ello emplearemos Task Parallel Library, esta se encuentra dentro del espacio de nombres System.Threading.Tasks.

Y su invocación es tan sencilla como:

Parallel.Invoke(() => Tarea1(), () => Tarea2());

Lo mas interesante de esto es que podemos enviar la cantidad de tareas en paralelo que deseemos

Parallel.Invoke(() => Tarea1(), () => Tarea2(), ()=> … TareaN());

Sin embrago siempre estamos limitados por los recursos del equipo, un gran número de proceso paralelos puede tener como consecuencia que el sistema baje su rendimiento.

Otro punto muy importante, por lo regular los equipos productivos tienen una potencia mucho mayor que los equipos de desarrollo, por tal motivo cuando se construye un proceso en paralelo se debe tener esto en mente.

Hasta la próxima semana.

6. Pensamiento Mágico, ayuda divina

Una actividad interesante, que debería desaparecer de nuestra mente, es emplear el pensamiento mágico de que solo se va a arreglar algo, si se arregla solo es que hay algo mal, algo esta tan inestable que el solo volverlo a hacer hace que funcione.

¿A qué se debe ese pensamiento mágico?, podríamos adjudicarlo a muchas cosas desde la inseguridad de que los pasos que se efectuaron son los correctos o la falta de conocimiento sobre cómo opera una aplicación.

Qué caso tiene hacer 100 veces la misma operación esperando que por pura casualidad en la 97 funcione, la computadora sigue una serie de pasos, específicos que no debería cambiar por ejecutar nuevamente una operación.

Pero, ¿Qué pasa si esto ocurre?, entonces no es que el programa se arreglara por sí solo, lo más probable es que exista un problema en la inicialización de algún objeto.

Ahora me dirán, es que la primera vez fallo, pero luego continuo, en este caso puede ser algún archivo temporal que sea necesario para que opere su programa.

Es común que digan reinicia y funciona, y esto en muchos de los casos es cierto, pero si esto ocurre realmente de lo que hablamos es de una inestabilidad del sistema operativo.

Es importante entender que nada se soluciona por arte de magia y menos en un mundo en el que todo se reduce a bits, a unos y ceros, en donde sí a la computadora se le dice enciende, esta enciende, 

Cuando un sistema esta inestable se debe hacer un análisis completo, de que estamos haciendo, cual es el flujo que sigue, esto nos ayudara a tener una mayor calidad en nuestros programas.

Hay que ser curiosos y no confiar en la solución mágica.

Hasta pronto

5. Herramientas - Mi propio NuGet

Divide y vencerás es una frase muy común en muchos de los entornos en los que nos desarrollamos, y en el software es algo que tiene una gran verdad, el hecho de que yo trabaje con componentes altamente especializados me ayuda a erradicar rápidamente errores y nos permite que el código sea altamente reutilizable.

Uno de los grandes problemas que ha existido a través del tiempo es como organizo mis versiones de código, para que de una manera sencilla los cambios en estos módulos especializados puedan llegar a los proyectos de mayor tamaño.

Bueno ante esto podemos hacer uso de la herramienta de administración de Paquetes llamada NuGet, NuGet es un administrador de paquetes de código abierto que trabaja sobre Visual Studio a partir de la versión 2010.

¿Qué tipos de archivos podemos poner en nuestra solución?

Prácticamente cualquier tipo de archivo, incluso en diferentes versiones de Framework dándole la posibilidad de emplear la dll en múltiples proyectos.

NuGet me permite que yo publique en la red mis dll pero también las puedo publicar en una red local, dentro de una carpeta compartida y que las consuman dentro de mi organización.

Para ello tengo que hacer lo siguiente:

1.       Descargar el NuGet Package Explorer desde la siguiente ruta:  https://npe.codeplex.com/, esta herramienta me permite generar los packetes de NuGet

2.       Al abrirlo me muestra esta pantalla:

3.       Se selecciona Create a new package

4.       Esto nos muestra la siguiente pantalla

5.       Se debe seleccionar el botón edición para editar las características del paquete

6.       Agrega la o las dll al proyecto

7.       Selecciona guardar como… y guarda este módulo en la carpeta que en que se creara tu NuGet personal.

8.       Ahora es necesario que visual studio conozca la ruta, inicia Visual Studio

Ve a Herramientas -> Administración de paquetes NuGet -> Configuración del administrador de paquetes.

9.       Y una vez dentro se selecciona la ruta en donde se encuentra nuestro paquete.

10.   Cuando buscamos el paquete este ya lo podemos usar en todos nuestros proyectos, es muy importante que se maneje el número de versión cada vez que se tengan nuevos dll ya que de esta manera NuGet tendrá la forma de asignar la nueva versión

Nos leemos pronto

4. Patrones de diseño

Un código bien diseñado, puede ser reusado con facilidad en otros proyectos,  adaptado para necesidades futuras y este operara de una manera correcta.

Pero que pasa en la programación salvaje, muchos códigos se diseñan para cumplir con un cliente específico, se tiene miedo a reutilizarlos porque se teme a que en algún momento se modifiquen y se pierda la funcionalidad original, el componente pertenece a otro más grande y reutilizarlo llega a ser complicado por el nivel de acoplamiento entre clases.

La gran cantidad de programadores que modifican un código y la poca o nula capacitación hace que cada uno de ellos implemente en sus proyectos funciones que anteriormente ya se implementaron.

Y bueno si supero esos obstáculos ¿Cómo logro hacer un código flexible que pueda emplear en múltiples proyectos y que realmente cumpla con la característica de ser reutilizable?

Un método para lograr esto es la implementación de patrones, por desgracia en .net existe muy poca gente que hace uso de ellos, a veces por tiempo, otras por desconocimiento, o porque en su organización no existen reglas para ello.

Un patrón de diseño es una solución que ya ha sido probada y que cuenta con una efectividad probada.

Así pues desde 1990 se han creado un conjunto de patrones de diseño, que permiten hacer software de mejor calidad.

En ese 1990 se recogieron 23 patrones de diseño estos fueron agrupados en la literatura por Erich Gamma, Richard Helm, Ralph Johnson,y John Vlissides, hoy son el conjunto básico de patrones que deberíamos conocer todos los desarrolladores, estos 23 patrones se dividieron en 3 grupos creacionales, estructurales y de comportamiento.

Existen 7 patrones estructurales que son:

• ·         Decorator
• ·         Proxy
• ·         Bridge
• ·         Composite
• ·         Flyweight
• ·         Adapter
• ·         Facade

Existen 5 patrones creacionales

• ·         Prototype
• ·         Factory Method
• ·         Singleton
• ·         Abstract Factory
• ·         Builder

Y existen 11 patrones de comportamiento

• ·         Strategy
• ·         State
• ·         Template Method
• ·         Chain of Responsibility
• ·         Command
• ·         Iterator
• ·         Mediator
• ·         Observer
• ·         Visitor
• ·         Interpreter
• ·         Memento

La calidad que se obtiene en un código de programación mejora cuando el desarrollador ocupa dichos patrones, ya que con esto se logra una verdadera estandarización en la codificación, y con ello acabaremos con esa programación salvaje.