Estándar Codificación y Trabajo v1.4b

Libero la v1.4b
La idea de incoporar un documento de Estándar de Codificación y Trabajo, empezó hace cosa de un año. El objetivo principal era el de plasmar un pequeño ejemplo de cómo definir un documento de este tipo y qué partido se le podí­a sacar, así­ como pequeñas ideas de qué elementos son “estandarizables” dentro del desarrollo de una aplicación.
El documento intenta cumplir un objetivo más didáctico que otra cosa, espero que os sirva para aportaros algunas ideas.
En esta versión, que se lanza aíºn como beta ya que los conceptos se han incorporado íºnicamente de forma parcial, se describen las siguientes casuí­sticas:

  • Nuevas cláusulas asociadas a la vista, como es el criterio a seguir a la hora de aplicar hojas de estilo.
  • Restructuración del apartado destinado al uso de la arquitectura de N-Capas, ampliándolo, y definiendo los accesos a seguir para cada una de las capas a aplicar. Se describen las orientaciones al respecto de la capa de acceso datos y la capa de datos

Saludos.
Miguel.

Estándar Codificación y Trabajo v1.3

Libero la v1.3
La idea de incoporar un documento de Estándar de Codificación y Trabajo, empezó hace cosa de un año. El objetivo principal era el de plasmar un pequeño ejemplo de cómo definir un documento de este tipo y qué partido se le podí­a sacar, así­ como pequeñas ideas de qué elementos son “estandarizables” dentro del desarrollo de una aplicación.
El documento intenta cumplir un objetivo más didáctico que otra cosa, espero que os sirva para aportaros algunas ideas.
Saludos.
Miguel.

Estándar Codificación y Trabajo v1.0

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.

Cómo Definir un Estándar de Codificación y/o Trabajo

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.