Mostrando las entradas con la etiqueta Calidad. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Calidad. Mostrar todas las entradas

viernes, 18 de diciembre de 2015

36. Patrones de Diseño (IV) - Proxy

Este blog inicio con la idea de construir un código ordenado, de hacer que nuestro código tuviera una mayor calidad, y hacer que el mantenimiento del mismo fuera menos costoso, nació porque hay muchas habilidades que debe tener un arquitecto antes de poder modelar una arquitectura de un sistema.

La sección de patrones de diseño se creó para brindar herramientas para evitar ese código salvaje, la sección sigue vigente, pero el blog ha crecido y junto con él se han incorporado nuevas secciones.

Pero hoy retomaremos los patrones de diseño, vamos a hablar de un patrón, que es muy sencillo porque su uso es muy común, tan común que mucha gente que no es desarrolladora, entiende el concepto o lo han usado principalmente para conectarse a internet, me refiero al patrón Proxy.

¿Qué hace el patrón proxy?, El patrón proxy juega como un intermediario que permite la creación y acceso de un objeto a otros, es decir me sirve como un puente entre objetos, su aplicación más común es el uso de proxies en internet, para acceder a paginas o para limitar el tráfico a las mismas.


Tratemos de ilustrar el patrón:


Contamos con una interfaz en la que se definen las tareas que se realizaran, esta interfaz se encuentra implementada tanto en el Proxy como en el objeto real.

El cliente consumirá la interfaz, de esta forma el Proxy se podrá agregar como intermediario sin necesidad de efectuar modificaciones en nuestro cliente.

Cuando el cliente efectué una llamada, nuestro cliente primero ira al proxy, en donde se puede agregar funcionalidad, después de eso el proceso se ira al objeto real.

Existen muchos tipos de proxy, entre los más comunes se puede mencionar:

Proxies Virtuales: Manejan la creación de objetos, en muchos casos hay objetos que requieren un tiempo muy elevado para su creación, este tipo de proxies pueden asumir la identidad del objeto como si ya estuviera creado, en lo que el verdadero objeto se genera.

Como es esto, el proxie invoca un objeto, el proxie en este caso es un objeto ligero pero que ya tiene las características del mismo, mientras el proxie crea el verdadero objeto, el proxie actúa como el objeto que se está creando, mostrando propiedades de manera preliminar.

Imaginen una clase de dibujo compleja con la que ya se puede interactuar, pero que varios de sus componentes se muestran con barras de carga, el proxy la clase compleja, que está construyendo los objetos que están en él.

Y como se crea, se construyen los métodos para tener las firmas, pero los datos se cargan conforme se está usando el objeto, estos datos se cargan en un segundo objeto, el objeto real.

Proxies de Autenticación: Muy comunes, su labor es establecer los permisos de acceso a un objeto.


El proxie tiene las mismas firmas que el objeto que se desea controlar, sin embargo analiza el acceso al mismo objeto, y si este no cumple con cierta característica no permite el acceso al mismo.


Proxie remoto: permite enviar información a través de la red comportándose como un objeto local, cuando se implementa el proxy efectúa las tareas de comunicación.

Proxie Inteligente: Puede efectuar cambios en el mensaje con condiciones específicas, por ejemplo una codificación, agregar atributos etc.

Como pueden ver es un objeto muy sencillo porque su función es solo servir de intermediario de mensajes pero que es muy útil en aplicaciones en el mundo real.


Hasta la próxima


jueves, 10 de diciembre de 2015

35. Buen Software

Mucho se ha hablado de 4 grandes características que debe tener todo software:

·         Mantenibilidad
·         Confiabilidad
·         Eficiencia
·         Usabilidad

Son características que todo arquitecto debe tener en mente al momento de diseñar una solución, vamos a repasarlas un poco.

Ya habíamos hablado de usabilidad en usabilidad estableciendo los 10 principios que menciona Jakob Nielsen

·         Visibilidad del estado del sistema
·         Relación entre el sistema y el mundo real
·         Control y libertad del usuario
·         Consistencia y estándares
·         Prevención de errores
·         Reconocimiento antes que recuerdo
·         Flexibilidad y eficiencia de uso
·         Estética y diseño minimalista
·         Ayuda a los usuarios a reconocer
·         Ayuda y documentación

Mantenernos dentro de estos nos da un gran paso, confianza al usuario, el sistema se convierte en algo que él entiende y que facilitara su trabajo, que es nuestra principal misión.

Eficiencia: Este es otro tema que hemos tocado en este blog, http://carlosamonroy.blogspot.mx/2015/06/mi-codigo-puede-volar.html , que quiere decir usar correctamente los recursos del sistema, hacer consultas rápida, administrar correctamente la memoria, optimizar código, en la actualidad hemos perdido mucho esa capacidad de optimización debido a que al tener hardware cada vez más robusto, dejamos mucho de este trabajo al hardware, desperdiciando una gran cantidad de recursos, el no optimizar nuestro software para lograr la máxima eficiencia, cobra su factura cuando este crece, cuando este sale de un ambiente controlado y empieza a consumir recursos que son por mucho superiores a los que esperamos.

No debemos depender del hardware, debemos buscar siempre hacer las cosas de una manera eficiente, en muchos casos esto ocurre al depender de muchos componentes de terceros, o de componentes que mejoran la interfaz gráfica, estos componentes llegan a ser muy pesados, componentes que en una primera impresión son buenos, peor que causan una gran molestia al enfrentarse a problemas reales.

Confiabilidad: característica de oro, el software debe ser confiable, esto se traduce en que debe hacer correctamente su trabajo todo el tiempo, que debe tener buenas prácticas de seguridad, la información es un bien y es uno de los bienes más valiosos, si el software no es confiable, puede causar resultados que van más allá de una falla en el sistema, un quiebra de una empresa, la muerte de 28 soldados que fue consecuencia de un error en un misil Patriot http://sydney.edu.au/engineering/it/~alum/patriot_bug.html

Mantenibilidad: Todo evoluciona, es necesario adaptarnos al cambio, el software debe nacer para que este pueda evolucionar fácilmente, vivimos en una industria que se mueve a una gran velocidad, los cambios se dan de un día a otro, el tener o no una ventaja competitiva depende de tomar las oportunidades cuando estas aparezcan, que la evolución del software se pueda dar, de una manera en que se puedan satisfacer rápidamente las necesidades del usuario


Hasta la próxima

viernes, 25 de septiembre de 2015

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

viernes, 11 de septiembre de 2015

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

jueves, 10 de septiembre de 2015

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