Bad practices

Desarrollo
Malas Prácticas de Programación

Versión Draft

Historial de Versiones

Fecha Versión Descripción Autor
30/01/2008 Draft Versión inicial LFavaro

Tabla de Contenido

1. PROPÓSITO 4
2. OBJETIVOS 4
3. CASOS 5

1. PROPÓSITO
Documentar todas aquellas situaciones en donde se encuentre código que no respete las buenas prácticas de programación consensuadas por el equipo dedesarrollo además de las cualidades del software. (Correctitud, confiabilidad, robustez, eficiencia, reusabilidad, mantenibilidad, legibilidad, portabilidad, amigabilidad, etc…
2. OBJETIVOS
• Unificar criterios de buenas prácticas de programación entre los diferentes integrantes del grupo de desarrollo identificando de manera clara y concisa qué es una mala práctica y cómo evitarla.
• Disminuirel número de malas prácticas de programación en el sistema reduciendo el tiempo del equipo de desarrollo y soporte asignado a la corrección de código y depuración de datos.
• Evitar caer en malas prácticas de programación consecuencia de malas prácticas anteriores.

3. CASOS

MP001 Autor: LFAVARO Fecha: 24/09/2009
Código a evaluar


ES MALA PRACTICA NO REUTILIZAR CODIGO YADESARROLLADO Y TESTEADO en instancias anteriores.

Se ha planteado que no reutilizar código se debe a que es difícil saber adónde buscar las rutinas. Por lo tanto, queda pendiente el generar un índice de todas las APIs para realizar operaciones puntuales en el sistema. Mientras tanto, acordamos buscar, preguntar, investigar antes de codificar. Claramente, aun no teniendo un índice de APIs, es menoscostoso buscar y preguntar, que desarrollar.

Observación
Se genera código redundante que requiere de un mayor esfuerzo mantener. Se corre el riesgo de introducir errores de manera innecesaria. Se invierte un mayor tiempo de desarrollo.
Código sugerido

REUTILIZAR CODIGO. SI NO EXISTE, GENERAR EL CODIGO ENCAPSULANDOLO Y UBICANDOLO EN UN LUGAR DONDE PUEDA REUTILIZARSE POR EL RESTO DELEQUIPO.

Ventajas Centraliza el mantenimiento. Aumenta la robustez del sistema. Menores tiempos de desarrollo a mediano y largo plazo. Menores tiempos de testeo por parte del equipo de Q.A.

MP002 Autor: LFAVARO Fecha: 30/01/2008
Código a evaluar

NO USAR PALABRAS RESERVADAS COMO VARIABLES DE ASIGNACION
Ejemplos: version , alias, long, roles, etc.
Observación
En general, encualquiera de las herramientas que usamos, al ingresar una palabra reservada esta se resaltada en otro color, por lo tanto, es realtivamente fácil evitarlas.
Código sugerido

En el caso de tener que usar el nombre, concatenarle otro string.

Ejemplo: version -> v_version
Ventajas Evitar comportamientos no deseados, mayor Legibilidad.

MP003 Autor: LFAVARO Fecha: 30/01/2008
Código a evaluarDECLARE
CURSOR c_alias_tabla (p_campo1 tabla.campo1%TYPE)
IS
SELECT *
FROM tabla alias_tabla
WHERE alias_tabla.campo1 = p_campo1;

r_alias_tabla c_alias_tabla%ROWTYPE;
v_campo1 tabla.campo1%TYPE;
BEGIN
OPEN c_alias_tabla (v_campo1);
FETCH c_alias_tabla INTO r_alias_tabla;
CLOSE c_alias_tabla;
END;
Observación
El select *instruye al compilador a crear todos los campos en el orden que conforman la tabla en el ambiente que se esté compilando, en el momento que se está compilando. Si existe una diferencia en los diferentes ambientes DESA, TEST, TRNG o PROD. Al ejecutar este query compilado en un ambiente con una estructura diferente al de compilación, se va a producir un error en tiempo de ejecución.
Código sugeridoDECLARE
CURSOR c_alias_tabla (p_campo1 tabla.campo1%TYPE)
IS
SELECT alias_tabla.campo2, alias_tabla.campo3
FROM tabla alias_tabla
WHERE alias_tabla.campo1 = p_campo1;

r_alias_tabla c_alias_tabla%ROWTYPE;
v_campo1 tabla.campo1%TYPE;
BEGIN
OPEN c_alias_tabla (v_campo1);
FETCH c_alias_tabla INTO r_alias_tabla;
CLOSE c_alias_tabla;
END;...