Buscar

entre unos y ceros

blog por Rubén Sánchez

Buenas prácticas

Es conveniente definir una guía de estilo antes de empezar un proyecto. El estilo hace referencia a cómo de entendedor es el código que escribimos.

Las buenas prácticas son convenciones. Cada programador tiene sus preferencias y se deben establecer unas pautas sin entrar en conflicto y valorando los ventajas e inconvenientes de cada estilo personal.

Además de hacer el código más fácil de entender, un buen estilo hace el código más fácil de mantener y ayuda a la consistencia global del proyecto. Las buenas prácticas de código hacen referencia a convenciones de estructuración del código, comentarios, nomenclatura de variables…

Programas como Resharper, CodeRush o  Justcode ayudan a hacer un código homogéneo y a tener un buen estilo, sugiriendo tanto convenciones de nomenclatura como otras buenas prácticas.

A continuación presento una guía de estilos personal que se puede utilizar como una base para definir una guía más compleja. Hay que ser consciente también que las guías de estilos no deben ser excesivamente rígidas ni complejas sino que deben ser fáciles de seguir y de adaptarse a ellas.

Convenciones de nomenclatura

Empezaremos revisando algunas nomenclaturas existentes:

Pascal Casing:  La primera letra de cada una de las palabras irá siempre en mayúsculas.se obvia el uso de artículos. Utilizaremos Pascal Casing para clases, propiedades públicas, métodos y eventos, constantes.

Camel Casing: Aquí existen dos variantes. Upper Camel y Lower Camel. Upper Camel Case es igual a Pascal Casing y en Lower Camel Case la única diferencia es que la primera letra irá en minúscula. Utilizaremos Lower Camel Casing para variables locales y parámetros en métodos, private protected variables miembro

Hungarian Notation: El nombre de la variable empieza con un grupo de letras en minúsucla que resepresentan un memotécnico del propósito de la variable o del tipo. Esta notación no resulta una buena práctica, puesto que ligar una variable a un tipo concreto en un lenguaje fuertemente tipado como c# no tiene mucho sentido.

Se desaconseja el uso de variables todo mayúsculas o con separación por underscore del tipo My_Class.

Los nombres de clase y las propiedades corresponden a nombres. Los métodos son verbos.

Las interfícies comienzan con el prefijo I: IMyInterface

Simplificar con namespaces. Utilizar using: using System.Drawing y no System.Drawing.Color.Red.

Declaración de tipos

Usar tipos predefinidos en vez de tipos de sistema. int y no int32, string y no String, bool y no Boolean.

Utilizar var en caso de duda.

Organización

Una clase, interficie o enum por fichero.

Nombre de fichero igual al nombre de la clase. Al renombrar el fichero nos pedirá si queremos renombrar la clase. Se deben refactorizar los nombres de las clases  en caso de que cambien los nombres de fichero.

Uso de namespaces => Company.Assembly.Folder.Subfolder

Braces (Llaves)

Vertical o Kenighan/Ritchie es correcto, pero se debe tomar una decisión y ser consistente con ella.

Declaración de miembros de la clase, arriba o abajo, los dos son correctos, pero se debe ser consistente. Utilizar los #region.

Estilo

Simplifica el código. ¿El código puede entenderlo cualquier persona? Simple no quiere decir menos lineas de código. Evita el último truco que has aprendido.

Los métodos deben hacer sólo una cosa. Aplicar SOLID.

Se debe ser consistente y coherente con las convenciones de nombre.

Usar propiedades en vez de variables públicas. Proporcionan métodos de acceso get y set. Se puede validar en el método set y permiten soporte de threading (se pueden bloquear en el método get)

Utilizar runtime vs constantes en tiempo de compilación.  Las variables en runtime son más flexibles, permiten tipos más complejos, por el contrario, const tiene una mejor rendimiento.

Usar String.Format o StringBuilder. Para concantenaciones simples de dos strings, + es correcto, pero no con variables.Usar String.IsNullOrEmpty y string.IsNullOrWhiteSpace. Para más recomendaciones sobre strings, hay varias recomendaciones aquí.

Al hacer el cast (conversión de tipo). Utilizar is y as en vez de hacer un casting.

Car car = (car) van; //esto puede lanzar un error

if (van is car) car = van as car;  //as devolverá null

Using y object disposal. Más información aquí.

Implementar IDisposable in las clases. En Dipose(), liberar recursos. Las clases pueden tener un bloque using.

Colecciones

Usar List<T> para iteraciones. El metodo Contains es lento.

Usar HashSet para buscar.

Usar SortedSet para listas ordenadas.

Usa colecciones en lugar de arrays.

  • Mas control sobre el contenido
  • Más flexible y más usabilidad

Usa arrays para minimizar el consumo de memora. Usa byte arrays en lugar de collection of bytes.

APIs

Usar IDictionary en vez de Dictionary, IDictionary<Tkey,TValue>

Usar IEnumerable<T> y Collection<T>

Exception Handling

Lanzar excepciones es costoso, tiene un impacto importante en el rendimiento.

Evita crear excepciones. Es importante controlar inputs antes de usarlos (null, index range, …)

Retorna error en lugar de lanzar una excepción.

try

{

//código

}

catch (Excepcion ex)

{

//tratar la excepción

}

finally

{

//limpiar los recursos

}

Evitar el uso de throw(new Exception(“XXX”));

Controlar excepciones específicas en vez de Exception tiene un mejor rendimiento.

Poner el mínimo código posible en try/catch.

Evitar los agujeros negro con catch vacíos.

Evitar control de excepciones en bucles.

MVC

Mantener la responsabilidad de cada capa.

  • Las vistas contienen únicamente presentación, no negocio. Crear un modelo para cada vista No compartir modelo entre vistas. Usar clases viewmodel para bindear datos. Evitar el uso de ViewBag.
  • El modelo contiene lógica de negocio. Interficie con la capa de datos, lógica de validación y reglas de negocio. Reglas de validación, cálculos, algoritmos…No debe haber lógica de presentación en el modelo.
  • Controladores son responsables de validación de entrada, enlazar los datos proporcionados por la capa del modelo con la vista. Usar sharedviews, partialview y HTMLHelpers.

Usar patrón PRG (Post-Redirect-Get). Más información aquí.

Errores

Evitar 404. Implementar HandleUnknownAction en el controlador. Retornar un vista de error o una página por defecto de error.

 

 

 

 

 

 

Event sourcing

Event Sourcing(ES) es un patrón de arquitectura que define un enfoque para las operaciones de manipulación de  datos. La idea es crear una secuencia de eventos , cada uno de los cuales se registra en un store.
En el modelo tradicional, la capa de negocio puede recuperar una fotografía de que valor tiene actualmente un determinado objeto. Por ejemplo, podemos recuperar que importe tiene la factura X, pero no podemos llegar a saber como hemos llegado a tener ese importe, a no ser que dispongamos de un log.  Hay momentos en los que no sólo quieren ver dónde estamos,  también queremos saber cómo llegamos allí.
En ES no hay ni modificación ni borrado, por lo tanto se necesita un mecanismo de persistencia que escale muy bien a nivel de escritura. ES trata de almacenar todo el estado del sistema únicamente como una secuencia ordenada de eventos.
La idea principal pues de ES es que cada cambio en el estado de la aplicación es capturado en un objeto evento y estos objetos se guardan en la secuencia que han sido aplicados. Entonces la pregunta es, que nos aporta este patrón que no podamos conseguir haciendo un sistema de log.

Seguir leyendo “Event sourcing”

DI, Light Inject y Service Locator

Vamos a ver, fuera de definiciones para que sirven y como se utilizan la inyección de dependencias. Para ello, lo mejor, es construir un pequeño programa de consola que iremos modificando y mejorando poco a poco, hasta llegar a la integración de la inyección de dependencias y el patrón Service Locator.

Aunque se que lo que planteo en este ejemplo se resuelve con un modelo de n-capas hoy no nos centraremos en eso, sino en ver un ejemplo de como se implementa la inyección de dependencias.

Imaginemos que tenemos un programa que implementa una agenda muy básica. Para simplificar vamos a centraros únicamente en crear un contacto. Los datos de nuestros contactos se guardan en un fichero.

Seguir leyendo “DI, Light Inject y Service Locator”

Programar de forma SOLIDa

SOLID (SRP,OCP,LSP,ISP,DIP ), son una serie de recomendaciones para el diseño de clases que se aplican en la orientación a objetos. Fueron descritas por Robert C. Martin, también conocido como “tío Bob” (Uncle Bob).

Hay que tener presente que SOLID son recomendaciones, no representan una obligatoriedad pero si que son buenas prácticas, utilizadas, consensuadas y demostradas. Conviene aplicarlas con sensatez, pero también es necesario tenerlas presentes a la hora de implementar y diseñar.

Para poder valorar la calidad de un diseño o de un desarrollo existen criterios como la rigidez, fragilidad o la inmovilidad que mejoraremos aplicando estas recomendaciones.

Por otro lado, hay que ser muy cuidadoso porque aspectos como la modularidad o la reutilización de clases nos puede llevar a una falta  de flexibilidad, robustez y reusabilidad  debido a la dependencia o alto acoplamiento entre las clases.

Seguir leyendo “Programar de forma SOLIDa”

Motivación

La falta de motivación y la apatía en los proyectos son resultado de fracaso o de productos mediocres. Muchas empresas aceptan la desmotivación como una etapa más del trabajador, la solución es reponer el trabajador y buscar carne nueva.

Resultado de imagen de motivacion

La desmotivación no es algo que un individuo busque o que aspire a ello. La selección natural favorece un sistema motivador. El hecho de que se asuma como normal muestra una carencia de visión global, de inteligencia emocional y de desconocimiento humanista.

Los integrantes de cualquier proyecto adquieren valor al mismo tiempo que adquieren experiencia. Aceptar el consumismo de recursos humanos al igual que aceptamos el consumismo de mercancía desgastada no es la solución.

He vivido como la desmotivación se contagia en el equipo. Los resultados empiezan a ser cada vez peores y se entra en una dinámica de reproches. Aumentan las tensiones y la frustración en el equipo.

Seguir leyendo “Motivación”

Documentación

El gran drama de todos los proyectos siempre suele ser la documentación. No sólo generar la documentación, que quizás este es el punto más sencillo, sino mantener y actualizar dicha información.

A veces se opta por simplificar y dejar la documentación limitada a los test cases que describe el QA, pero al final, la búsqueda concreta del comportamiento específico de una funcionalidad del software genera una gran pérdida de tiempo y se acaba antes preguntando al equipo sobre qué hacía tal o cuál función del programa que revisando la documentación.

Esta perspectiva en sí no es mala ni buena, sino que es una realidad. Es por ello que la implicación en el proyecto y la solidez del grupo aporta un nivel de conocimiento de la aplicación mucho mayor que cuando se trabaja individualmente a expensas de una documentación.

Aún así la documentación sigue siendo muy importante, y se debe conseguir un equilibrio entre documentar mucho y con demasiado contenido irrelevante, y documentar con lo fundamental, de forma ágil y entiendo que tenemos que documentar de una forma útil para todos aquellos que después van a leer esa documentación

Seguir leyendo “Documentación”

Programación asíncrona

Hoy en día la velocidad de los procesos, y por ende de los programa es crucial. Disponemos de procesadores muy potentes y como buenos diseñadores y programadores tenemos que saber sacar partido al alto rendimiento y procesamiento que nos permiten las máquinas.

Un procesador no puede quedar esperándose sin trabajo que realizar. Es decir, no podemos ser bloqueantes. Tenemos que saber ordenar las operaciones que realizamos, lanzar antes aquellas que preveemos que las utilizaremos más tarde y consumirán tiempo de procesador.

Entender como funciona la asincronía se convierte en algo fundamental si queremos hacer aplicaciones rápidas y eficientes. El problema es que la asincronía introduce algo de complejidad a nuestro código y debemos ser cuidadosos a la hora de utilizarla, poniendo especial atención en cumplir las buenas prácticas que nos evitarán dolores de cabeza.

Seguir leyendo “Programación asíncrona”

Trends & predictions

Si adaptásemos cada última tendencia en el ciclo de vida de una aplicación, este sería infinito. La novedad tiene un coste. Claramente también tiene la ventaja de si se acierta, estarás un paso por delante ante los que se quedaron esperando ver qué tal se comportaba el mercado ante la predicción. 

En informática existe una línea muy fina entre estar dentro de un rango actualizado y estar desfasado , a veces podemos hablar de meses. Además, una vez entras en la dinámica de la desactualización, cada vez cuesta más encontrar el momento para ponerse al día. 

Seguir leyendo “Trends & predictions”

La nube azul

Hace un tiempo empecé a utilizar Azure en el trabajo. Desde mi punto de vista Azure ha sido uno de los grandes aciertos de Microsoft en los últimos tiempos. Azure es una plataforma y servicios de informática en la nube, así lo definen ellos. Azure es comidad, simplicidad y robustez. 

Seguir leyendo “La nube azul”

Blog de WordPress.com.

Subir ↑