Control de Calidad

Índice

Convenciones a la hora de escribir código

Sabemos que todos tenemos nuestro estilo de programar, pero para el que revise y pruebe el código, va a ser más fácil si todos escribimos de una forma homogénea.

1. Habrá una y sólo una sentencia por línea. Es decir cosas como:

i++; juan = pepe + pacho; j--;

estarán prohibidas. Lo correcto sería:
i++; 
juan = pepe + pacho; 
j--;

2. Los nombres de las clases en Java empezarán con letra mayúscula.

3. Los nombres de los métodos de cada clase empezarán con minúscula.

4. Los nombres de los atributos de cada clase empezarán con guión bajo. Ejemplo:

private String _nombre;
public Integer _numero;

Los parámetros de las funciones y las variables locales a los métodos empezarán SIN guión bajo, así se pueden diferenciar mejor el contexto de las variables.

5. Los métodos y atributos estáticos de las clase cumplirán con las reglas anteriores anteponiendo "st" al nombre elegido. Ejemplo:

private static String _stNombre;
public static Integer _stNumero;

6. Las constantes llevarán su nombre completo en mayúscula y si hay que separar palabras se hará con guiones bajos. Por ejemplo:

private static java.awt.Color COLOR_FONDO;
public static String NOMBRE;

Las constantes siempre serán variables estáticas, con lo cual no pondremos el prefijo 'st' en sus nombres.

7. Para los nombres de métodos, variables y clases, para separar palabras se introducirán mayúsculas. Por ejemplo:

private String _primerApellido;
private String _segundoApellido;

8. Trataremos de usar nombres de variables representativos. Nada de expresiones tipo "a = b * c", porque nos va a costar identificar qué es cada cosa.
Vamos a tardar más en escribir, pero después será mucho mejor a la hora de modificar y corregir el código.
Todos tenemos que entender el código de todos.

9. El código deberá estar correctamente tabulado.

Código en Java

  • Se tratará de documentar TODO con JavaDoc. Todo quiere decir, métodos (con sus parámetros y lo que devuelven) y variables (lo que representan y su propósito).
  • Los atributos de las clases se ubicarán al PRINCIPIO de las mismas.
  • Los métodos estarán ubicados en el siguiente orden:
                                1. Constructoras
                                2. Métodos de uso general
                                3. Accesoras
                                4. Seteadoras
  • Las variables de los elementos gráficos tendrán que tenér nombres representativos, como se dijo en la regla 8. No sirve que algo se llame jButton1.

Estructura de paquetes

Cada grupo estará encargado de actualizar (refactorizar) su código a la nueva nomenclatura de paquetes que es la siguiente.

Estructura_paquetes.png

Como se puede ver en el diagrama, los nombres de los paquetes serán estructurados
del siguiente modo:

  • Para los módulos el nombre será IStation.Modulos.nombreModulo. En caso de que los módulos tengan parte "Cliente" y "Servidor" diferenciadas, se añadirá al final del nombre del paquete .Servidor ó .Cliente según corresponda. Finalmente si se trata de características comunes a módulos se añadirá .Compartido.
  • IStation.Servidor está referido al cargador de módulos del servidor. Fue incluido en la rejarquía para que se aprecie la diferencia entre dicho paquete y los del tipo IStation.Modulo.nombre_modulo.Servidor o IStation.Modulo.nombre_juego.Servidor
  • Respecto a los juegos, el nombre de los paquetes siguen una estructura similar al de los módulos con la única diferencia de donde pone Modulos sustituirlo por Juegos.

Controles al código entregado

Condiciones de envío

  1. Que al menos compile.
  2. Que cumpla con todo lo detallado en el punto anterior.
  3. Haber hecho algún testeo previo para ver que funciona con casos generales.
  4. Que no repita código de otros lados, hay que tratar de utilizar el código que ya esté implementado. Por ejemplo como métodos de ordenación y cosas por el estilo.

Metodología de control

Habrá algún miembro del grupo designado para coordinar el control e integración de todos los módulos del proyecto.
Igualmente, para que no sea siempre la misma persona a lo largo de todo el curso el puesto de revisor irá rotando. Además alguien tendrá que revisar el código que produce el revisor.

Revisiones

Al finalizar cada iteración mensual cada pareja "revisora" deberá elaborar un informe que quedará asentado en la documentación para que pueda leerlo la pareja "revisada" y corregir los errores observados.

Dicha páginas de informes se encuentra aquí.