Ingeniería de Software, Gestión de Proyectos, Programación, BPM, Arquitectura de Software, .NET, J2EE
Después del otro día donde empezamos a hablar de estándares de código, me ha parecido buena idea ir recopilando las ideas en diferentes versiones de un documento de estandarización.
En esta primera versión, la v1.0, incorporo los apuntes al respecto de creación de tablas, controles, y ya que estamos algo de organización de carpetas.
Iremos completando poco a poco.
Estándar Codificación y Trabajo v1.0
¿Aportaciones?
Saludos.
Miguel.
En muchas aplicaciones suele ser común que existan conjuntos de datos que cambien muy poco o nada a lo largo del tiempo. Por ejemplo, si almacenamos en nuestra base de datos tablas con Países, Provincias, Comunidades Autónomas… lo más seguro es que los registros que conformen la tabla no varíen en el tiempo o si lo hacen sean cambios totalmente excepcionales.
Si esto es así e imaginando el típico formulario web donde tenemos que seleccionar un desplegable con provincias, podría resultar ineficiente hacer una consulta a base de datos por cada carga del formulario que realizaran los distintos usuarios de la aplicación. ¿Para qué vamos a consultar otra vez la base de datos si podemos asegurar en un 99% que no habrán cambiado? Sobre todo teniendo en cuenta que el acceso a base de datos suele ser de lo que más penaliza el rendimiento de una aplicación.
Una buena idea sería que en según que métodos de nuestra capa de acceso a datos, antes de realizar una consulta directa a una tabla, comprobáramos si los datos ya se han almacenado en entidad física mucho más rápida de acceder que la base de datos, por ejemplo, en una caché. Inicialmente esta caché estaría vacía, en la primera carga se rellenaría a partir de la información de la base de datos, y el resto de veces ya se atacaría siempre a la memoria cache.
El resultado, claramente es un tiempo de respuesta mucho más bajo en cada transacción de este tipo.
¿Algún ejemplo con pseudo-codigo?
public Lista<ProvinciaDTO> GetProvincias()
{
if (IsVacio(CacheProvincias))
{
CacheProvincias = RellenaConAccesoATablaProvincias();
}
return TransformaCacheEnLista(CacheProvincias);
}
Como véis sólo rellenaremos la caché de provincias con los datos de la tabla si la caché está vacía, si no lo está, directamente retornaremos los datos desde la caché.
En el pseudo-código no se están resolviendo temas de concurrencia (cómo resolver si dos usuarios al mismo tiempo comprueban si está vacío y da verdadero), y se abstrae 100% la solución propia de cómo cachear precisamente para hacerlo independiente de la tecnología en que queráis aplicar el método.
Otro tema interesante que podrían incorporarse, es la posibilidad de que la caché caduque, es decir, que no se almacene la información en la caché de forma infinita mientras la aplicación no se reinicie, si no que se establezcan periodos temporales en los como máximo la caché será renovada. Por ejemplo si tenemos una tabla que almacene Marcas puede que nos interese que se reuneve la caché cada 24 horas ya que almenos una vez al día se añade una marca nueva (me lo estoy inventando obviamente, es por dar un ejemplo). Si ante la petición de un usuario se comprueba que la caché está caducada, esta se vaciaría y se volvería a rellenar de forma automática tras una consulta a la tabla correspondiente de la base de datos.
¿Interesante?
Saludos.
Miguel.
Vamos a aprovechar algún comentario en el blog al respecto de información asociada a UML para dejar para empezar algún link que pueda serviros de referente para empezar a empaparos.
Os los ordeno un poco en el orden que recomiendo leerlos para que os vaya quedando todo un poco más claro.
1) Historia de UML, qué es UML. Muestra superficial de algunos diagramas
2) Pequeños ejemplos de los diagramas UML más comunes
3) A fondo UML de casos de uso
4) A fondo UML diagrama de clases
Un saludo.
Miguel.
Supongo que muchos de vosotros trabajaréis en proyectos en los cuales puede que exista un estándar de trabajo, un método, una forma definida de hacer las cosas. Este estándar puede venir definido a nivel de empresa, a nivel de proyecto o incluso a nivel de vuestro propio cliente.
Para los que no disponéis de dicho estándar puede que en un momento dado os veáis en la necesidad de definirlo. La primero pregunta que vamos a responder al respecto es, ¿para qué necesitamos un estándar?
1) Eleva la mantenibilidad de nuestro código.
2) Sirve como punto de referencia para los programadores.
3) Mantiene un estilo de programación.
4) Ayuda a mejorar el proceso de codificación, haciéndolo entre otras cosas más eficiente.
Una vez que tengamos claro que necesitamos definir un método podemos hacer dos cosas, o nos pasamos los días definiendo en un documento todo lo que se nos ocurra al respecto, o ir retroalimentando poco a poco un documento a medida que van surgiendo las necesidades de estandarización. Esta segunda forma es la que me gustaría presentaros, y no porque sea un método formal al respecto, si no como una manera de ir definiendo algo que es realmente pesado, de forma cómoda y consensuada con el propio equipo de desarrollo.
Sería además ideal disponer de la posibilidad de poner la definición del estándar en marcha a partir de una nueva aplicación de no muy grandes dimensiones.
Por ejemplo, un apartado que podría formar parte de nuestro estándar de codificación / trabajo es qué reglas deben seguirse al definir un modelo entidad-relación de base de datos. Os pongo un ejemplo de algunas
1) Todas los nombres de las tablas estarán en mayúsculas y en singular. Ejemplo: COCHE, MARCA, ELECTRODOMESTICO
2) En caso de que el nombre de una tabla conste de más de una palabra, los espacios en blanco se marcarán con un guión bajo. Además, todas las palabras seguirán estando todas en singular. Ejemplo: LINEA_FACTURA, MOTOR_AVION.
3) La clave primaria de una tabla siempre llevará el prefijo “COD_” y a continuación el nombre de la tabla. Ejemplo para la tabla COCHE: COD_COCHE, para la tabla LINEA_FACTURA: COD_LINEA_FACTURA
4) Los campos de tipo fecha llevarán el prefijo “FX_”. Ejemplo, para la fecha de alta: FX_ALTA.
5) A la hora de crear un script de actualización se debe seguir la siguiente nomenclatura en el archivo NNNN_CREATE|ALTER|DROP_NOMBRETABLA.sql. Siendo NNNN un número secuencial, CREATE-ALTER-DROP la acción ejecutada en la secuencia SQL y NOMBRETABLA el nombre de la tabla donde se ejecuta la acción.
Como véis esto no tiene mucha historia y es algo que podemos definir en un momento al mismo tiempo que estamos creando las primeras relaciones de nuestra nueva aplicación. Siguiendo estas súper sencillas directrices vamos ya a garantizar que todas las tablas de nuestra nueva aplicación van a seguir una misma guía de estilo. No vamos a entrar a discutir si son buenas o malas definiciones, pero eso sí, al menos son definiciones que van a permitir trabajar de la misma manera a todas las personas que trabajen con la aplicación. Si con el tiempo se comprueba que se pueden mejorar, se modifica el estándar para que se aplique de la nueva forma en próximos desarrollos.
Más ejemplos de otros apartados de estandarización es cómo llamar a los controles que aparecen en un formulario
1) Para un Textbox utilizar el prefijo “TxT”. Ejemplo: TxtNombre
2) Para un Label utilizar el prefijo “LbL”. Ejemplo: LblApellido
3) Para un Button utilizar el prefijo “Btn”. Ejemplo: BtnAceptar
El nivel de estandarización que queráis alcanzar dependerá de vuestras necesidades. Cuanto más queráis abarcar mayor control tendréis y más complicado va a ser el tener presente todos los puntos.
Bajo mi punto de vista la clave es mantener el documento lo más vivo y en contacto del equipo de desarrollo posible. Retro-alimentarlo continuamente con mejoras, tener muy claro que la definición inicial no tiene por qué ser la mejor o más completa. Añadir ejemplos que dejen claro el uso.
Saludos.
Miguel.
El próximo jueves 8 de mayo se va a producir un evento on-line por parte de Microsoft relacionado con la Arquitectura Orientada a Servicios.
La descripción del evento es la siguiente:
“Uno de los temas más polémicos en los últimos tiempos en Arquitectura de Software es la orientación a servicios, y cómo esto mejora la agilidad, flexibilidad y el rehúso de mis soluciones. En esta sesión, nos enfocaremos en la orientación a servicios desde una perspectiva de arquitectura de software, analizaremos cómo un enfoque orientado a servicios difiere de arquitecturas basadas en objetos y componentes, así como también la discusión de algunos retos organizacionales que se experimentan al adoptar una arquitectura orientada a servicios”
Muy interesante a priori, el único problema es que para poder verlo en directo tendréis que estar delante del ordenador de 11 a 12 de la noche… 
O esperar más adelante a que pongan a disposición la grabación para ver el vídeo off-line.
Mas información y suscripción al evento Aquí
Un saludo.
Miguel.