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.