Anti Patrones Parte I

¿Por dónde empezar?, un anti patrón, por así decirlo, es un patrón mal aplicado que nos lleva a una mala solución. Veamos algunos.

Anti-patrones de Gestión de Proyectos

1- Productividad a toda costa: La empresa busca la productividad a costa de la calidad del software y de la calidad de vida de sus empleados, intenta normalizar los puestos de trabajo quitando en la medida de lo posible, los permisos a los programadores para que no dañen los sistemas operativos, monitoriza a los equipos de trabajo y actúa cortando la visibilidad de ciertas páginas o reuniones de programadores, al final la gente abandona la empresa cuando la situación ya es insostenible, esto suele ocurrir en ciclos de uno o dos años.

2- Mas programadores, para reducir el tiempo de entrega. Muchas veces para arreglar el retraso en la entrega de un proyecto se suman mas programadores a un equipo, lo cual suele juegar en contra llevando a un mayor retraso.

3- Jefes/as que no saben coordinar un equipo, el proyecto no se monitoree de manera correcta. Esto suele llevar a retrasos en los tiempos de entrega o entregas incompletas.

Anti-Patrones en el código

1- Vulcan Code: se caracteriza por tener clases con grandes cantidades de código, poco documentadas variables declaradas que no se usan o que no son necesarias.

Se utiliza un estilo poco claro en evolución la arquitectura.

Es un proyecto que tiene mucho código por reemplazar o mejorar por ejemplo: métodos que no se invocan, objetos o componentes que no se utilizan, interfaces abandonadas, etc.

2- Spaghetti Code: si bien tiene mucha similitud con “Vulcan Code”, este anti-patrón se caracteriza además por utilizar mas de un lenguaje en el desarrollo y por tener una arquitectura frágil con lo cual el menor cambio afecta de manera drástica toda la estructura del sistema.

3- Ghosts (Fantasmas): se caracteriza por tener varias clases en el sistema o tablas en la base de datos con pocas responsabilidades. Este anti-patrón suele darse cuando un modelo de análisis y/o diseño es inestable: el diseño no suele coincidir con la implementación y ampliar el sistema es poco probable, dado que habiendo tanto “fantasma”, encontrar los elementos relevantes es imposible.

Anti-Patrones en la Arquitectura

1- Reinventar la rueda, es uno de los anti-patrones más típicos, se caracteriza por la poca reutilización de código y el reescribir código en lugar de implementar componentes ya existentes.

2- Stovepipe (cañerías de calefacción): Se refiere a construir un sistema que difícilmente se puede mantener ya que está ensamblando por componentes poco relacionados. Un ejemplo de esto sería la creación de islas dentro de la misma empresa (cada departamento crea su propio subdepartamento de sistemas). “Islas” independientes, y en conflicto unas con otras. Cada isla desarrolla la parte del sistema que necesita para satisfacer sus requerimientos, sin preocuparse por el resto (no existe un plan o eje guía), los resultados son una pobre o nula interoperabilidad y un incremento en los costos. Este anti-patrón es mas habitual de lo que se cree.

Espero les guste este articulo. Pronto escribiré la segunda parte.

Gracias por visitar mi blog.

Anuncios

Buenas Practicas de Programción en c# Segunda Parte

Como lo prometido es deuda, aqui estoy con la segunda parte del post de Buenas Practicas de Programacion en c#.

Comencemos con SQL

En base de datos, es recomendable:

1. Stored Procedures deben nombrarse con prefijo “spr_”. NO usar nunca “sp_”, La razón es que: SQL Server reconoce el prefijo “sp_” como “System Stored Procedure”, es decir, un procedimiento almacenado de Sistema y lo buscaría en la Base de Datos “Master”.

2. Tablas “tbl_” ….

3. Vistas “vw_” …

Volviendo al código c#

1. Usa #region para agrupar código. En mi caso suelo usar de la siguiente manera

#región –[Variables Privadas]– #End Region

#región –[Propiedades Privadas]– #End Region

#región –[Metodos Privados]– #End Region

#región –[Eventos]– #End Region

#región –[Propiedades Publicas]– #End Region

#región –[Metodos Publicos]– #End Region

la idea es mantener las variables globales, las propiedades y los métodos, todos ellos privados en la parte superior del archivo y los elementos públicos en la parte inferior.

Metodos

1.  Un método debe tener entre 1 a 25 líneas de código. Si un método tiene más de 25 líneas de código, debes considerar refactorizarlo en métodos separados.

2. El nombre de los métodos debe decir lo que hace. Si el nombre del método es obvio, no hay necesidad de summary.

3. Un método debe tener solo “una tarea”. No combines más de una tarea en un solo método, aún si esas tareas son pequeñas.

4. Evita métodos y propiedades públicas, a menos que ellas realmente necesiten ser accedidas desde afuera de la clase. Usa “internal” si ellas solo son accedidas dentro del mismo ensamblado. Normalmente pocos usan esta buena práctica, es muy recomendable.

5. Evita pasar muchos parámetros a un método. Si tienes más de 5 parámetros, define una clase o una estructura. Esto reduce el consumo en memoria, evita la corrupción de datos, y disminuye la exigencia a los ciclos del procesador.

6. Si tienes un método que retorna una colección, devuelve una colección vacía en vez de null, si no existen datos que retornar. Esto permite hacer una verificación por un count en vez de por null y luego por count.

Constantes, strings y de mas

1. Usar constantes en el código, no es recomendado.  Se debe usar las constantes en el archivo de configuración o en la base de datos, de tal forma que si a futuro deben cambiarse, sea menor el impacto.

2. Si debes comprar cadenas de texto recuerda convertirlas a mayúsculas o minúsculas según corresponda, estoy permitirá una mejor comparación.

3. Usa string.Empty en vez de “”.

4. Usa enum en donde sea requerido. No uses números o cadenas para indicar valores fijos

enum TipoCorreo
{
Html,
TextoPlano
}

switch ( tipoCorreo )
{
case TipoCorreo.Html:
//hacer algo
break;
case TipoCorreo.TextoPlano:
// hacer algo

}

5. Los eventos no deben contener el código que ejecute la acción requerida. En vez de ello, se debe llamar a otro método desde dicho evento, ejemplo:

protected void btnObtenerDatos_Click(object sender, EventArgs e)
{
ObtenerDatos();
}

6. De la mano del punto anterior, no invoques desde código el evento Click, en vez de ello llama al método que es invocado desde el evento click.

7. No utilices código duro en rutas o letras de dispositivos. Obtén la ruta desde código.

8. Cuando inicia la aplicación, ejecuta una clase de “auto verificación” para asegurarte que todos los archivos requeridos y las dependencias están disponibles en las ubicaciones esperadas. Verifica las conexiones a la base de datos. En caso de algún problema, muestra un mensaje amigable al usuario.

9. Si el archivo de configuración requerido no se encuentra, la aplicación debe ser capaz de crear uno con valores predeterminados.

10. Cuando despliegues mensajes de error,  el mensaje también debe decirle lo que el usuario que debe hacer para resolver el problema. En vez de un mensaje como “Error al actualizar tus datos.”, sugiere lo que el usuario debe hacer: “Error al actualizar los datos, comprueba que tienes acceso a internet e inténtalo de nuevo.”.

11. Evita tener clases muy grandes. Si una sola clase tiene más de 1000 líneas de código, es un buen candidato para refactorizar. Divídelos lógicamente en dos o más clases.

Bueno esto es todo por hoy, muchas gracias por leer mi blog y espero te sirva de ayuda. En estos días prepararé la ultima entrega de buenas practicas, si deseas de que trate algún tema en especial por favor comunícamelo. Hasta la próxima.

Buenas Practicas de Programción en c# Primera Parte

Hola, hoy voy a empezar con la primera parte de las buenas Prácticas de Programación en .NET, esto no es algo que se me ocurrió a mí, sino que son estándares usados para programar y así generar un código mas entendible por si a futuro debe ser analizado y/o modificado por algún colega no sufra dolores de cabeza intentando entender lo que hicimos, bueno sin mas vueltas vamos al grano.

Comencemos con un poco de teoría de notaciones:

Los términos “notación Pascal” y “notación de Camell”

Notación Pascal: El primer carácter de todas las palabras se escribe en Mayúsculas y los otros caracteres en minúsculas. Ejemplo: EstadoDeEnvio

Notación de Camell: El primer carácter de todas las palabras, excepto de la primera palabra se escribe en Mayúsculas y los otros caracteres en minúsculas. Ejemplo: estadoDeEnvio

Buenas Practicas I

No se deben usar  guiones bajos (_) para nombres de variables locales generalmente el guión bajo (_) está reservado para variables globales, de tal forma que puedan ser identificadas de las variables locales.

Variables booleanas: es conveniente usar el prefijo “Es” ó “Is” para variables de tipo boolean o prefijos similares. Ejemplo: private bool EsValido private bool IsActivo La propuesta de “Is” es la más aceptada, ya que es coherente con las propiedades de uso global de .NET, por ejemplo: objeto.IsEmpty(); de esta manera el IntelliSense agrupa de una forma más coherente.

Los nombres de los espacios de nombres deben seguir el siguiente estándar: <NombreDeCompañía>.<NombreDeProducto>.<MóduloSuperior>.<MóduloInferior>

namespace northwind.GestionDeFacturacion.Facturas.Proveedores

Los nombres de Clases o Métodos y funciones deben seguir el estándar:

<Accion/Verbo en Inglés><descripción> GetProveedores(); AddProveedores();

Lo cual permite al IntelliSense agrupe de manera más optima con el resto de métodos generales de los objetos.

Usar prefijos apropiado para cada elemento de la interfaz gráfica. Dado que .NET tiene una gran cantidad de controles, se tiende a utilizar los siguientes prefijos

Label: lbl

TextBox: txt

DataGrid: dtg

Button: btn

ImageButton: Imb

Hyperlink hlk

DropDownList: ddl

ListBox: lst

DataList: dtl

Repeater: rep

Checkbox: chk

CheckboxList: cbl

RadioButton: rbt

RadioButtonlist: rbl

Image: img

Panel: pan

PlaceHolder: phd

Table: tbl

Validators: val

Gracias por tu visita, espero te haya servido de ayuda, pronto estaré escribiendo la segunda parte de buenas prácticas, si deseas de que escriba sobre algún tema en especial por favor comunícamelo.

Saludos