PDF de programación - CONOCIMIENTO DE PROGRAMACIÓN MÍNIMO REQUERIDO PARA CONSTRUIR PROGRAMAS DE BUENA CALIDAD

CONOCIMIENTO DE PROGRAMACIÓN MÍNIMO REQUERIDO

PARA CONSTRUIR PROGRAMAS DE BUENA CALIDAD

MINIMUM KNOWLEDGE ON PROGRAMMING REQUIRED TO Write GOOD QUALITY



PROGRAMS

Adolfo Di Mare

Escuela de Ciencias de la Computación e Informática, Universidad de Costa Rica

[email protected]



RESUMEN: Aunque muchas personas tienen los conocimientos básicos para escribir pequeños programas,
no todos los programadores tienen los conocimientos de programación que se definen en este trabajo, los que
son fundamentales para escribir programas de buena calidad.

Palabras Clave: Abstracción, especificación, módulo, reutilización, prueba de programas, pruebas unitarias.

ABSTRACT: Although many people have the basic knowledge to write small programs, not all developers
have the programming skills defined in this paper, which are essential for writing good quality programs.

KeyWords: Abstraction, specification, module, reuse, software testing, unit testing.


1. INTRODUCCIÓN
La calidad es un concepto relativo, pues depende
del contexto en que se define. Por ejemplo, hoy en
día ya no es necesario que un reloj de pulsera esté
construido para que funcione durante siglos, pues
muchos de esos aparatos se usan durante poco
tiempo (a veces son sustituidos antes de un año).
Otros objetos, como por ejemplo los guantes para
lavar platos o las toallas húmedas de papel, están
diseñados para tener una vida útil muy corta. En la
industria de la computación, la calidad tiene un
significado que también depende del contexto, pues
si un programa se usará solo una vez no vale la
pena invertir lo suficiente para que funcione durante
esa única ejecución.
En lugar de elaborar un tratado teórico sobre lo que
debiera saber un programador, el enfoque que aquí
se usa es de ingeniería inversa, pues se destacan
algunas carencias o defectos que deben ser corre-
gidos en los programas, y con base a esa enume-
ración de deficiencias se define cuáles conocimien-
tos debe tener un programador que produce soft-
ware de calidad. Además, con el fin de lograr que

esta definición de competencias del programador
sea de utilidad práctica inmediata, en lugar de usar
un concepto de calidad que contiene muchos atri-
butos deseables, se ha escogido la ruta más directa
al homologar el concepto de calidad con el de me-
jora y mantenimiento de programas. Esta simplifi-
cación del problema deja muchas áreas del control
de calidad por fuera, pero tiene la ventaja de que
hace posible definir los conceptos en el reducido
espacio de un artículo académico como este.

2. ESPECIFICACIÓN
Sin especificación no hay calidad. Es fácil encontrar
personajes ilustres que justifican el uso de especifi-
caciones para construir programas [1],[2].
Sin embargo, no es difícil reconocer por qué es
necesario hacer especificaciones si se usa la ana-
logía del “hombre del rifle”: si uno dispara antes de
apuntar, termina con una bala en el dedo gordo del
pie. Si uno programa antes de especificar, termina
programando otra cosa.
Ayuda mucho que cada módulo tenga una descrip-

“VI Taller Internacional de Calidad en las Tecnologías de la Información y las Comunicaciones ”



Di Mare | “Conocimiento de Programación Mínimo Requerido para Construir Programas de Buena Calidad”



ción corta que describa, en una frase, cuál es la
funcionalidad implementada. A veces los progra-
madores escogen nombres para cada rutina que
oscurecen su función (como cuando llaman suma-
a un módulo que hace restas), pero lo usual
dor()
es que el nombre del módulo tenga una descrip-
ción, talvez demasiado corta, de su funcionalidad.
Lo especificación mínima es darle un nombre signi-
ficativo a cada módulo y por eso siempre es nece-
sario escoger buenos identificadores en cualquier
programa.

long mcd();

La especificación de un módulo define su funciona-
lidad. En lugar de describir cuál es el algoritmo
utilizado, más bien en la especificación se explica
cuál es el cambio que resulta de la ejecución de la
rutina. Este cambio resulta en la modificación de los
valores almacenados en los parámetros, lo que
implica que en cualquier especificación es necesa-
rio definir cuáles son los parámetros y en qué con-
siste la modificación de sus valores. Algunos módu-
los crean objetos nuevos, como ocurre con el que
suma 2 matrices que debe retornar una nueva ma-
triz, sin modificar sus argumentos. También es po-
sible utilizar variables globales cuyo valor queda
modificado como efecto colateral de la ejecución
del módulo, pero generalmente se trata de evitar
esta práctica porque es difícil lograr localizar cuáles
variables globales son afectadas por algún módulo:
de aquí nace la regla que dice “minimice el uso de
variables globales”.

long mcd( long a, long b);

Además de usar nombres adecuados para el módu-
lo y sus parámetros, es importante incluir en la es-
pecificación al menos una frase corta que diga qué
hace: “suma los valores de la lista”, “encuentra el
valor de corte”, “calcula el valor de retorno”, “en-
cuentra el interés de referencia”, etc. Esta descrip-
ción corta generalmente se incluye como un co-
mentario que está en el encabezado del módulo.

// Calcula el Máximo Común Divisor
long mcd( long a, long b);

3. DOCUMENTACIÓN INTERNA
Sin documentación interna no hay calidad. Muchas
son las razones por las que es necesario modificar
un programa, pero generalmente la modificación se
localiza en uno o varios módulos. Puede ocurrir que
quien deba hacer la modificación sea la misma
persona que construyó el módulo, pero si el siste-

ma es de tamaño mediano o grande, lo más proba-
ble es que cada modificación sea llevada a cabo
por una persona diferente.
Si la implementación no tiene documentación algu-
na, quien deba darle mantenimiento al módulo debe
estudiar el código fuente para deducir, en un proce-
so de ingeniería inversa, cómo funciona. Por eso,
también es importante decorar el algoritmo utilizado
con comentarios cortos y concretos, que permitan
después entender con mayor rapidez cómo funcio-
na el módulo.

// Calcula el Máximo Común Divisor
long mcd( long a, long b ) {
// solo trabaja con positivos
long g = ( (a<0) ? -a : a );
long r = ( (b<0) ? -b : b );
long tmp; // "r" es el resto

do {
tmp = r;
r = g%r; // módulo en común
g = tmp;
} while (0 != r);

return g;
} // mcd()

4. ESPACIADO E INDENTACIÓN
Sin espaciado e indentación no hay calidad. A ve-
ces los programadores se ahorran algunas teclas al
escribir sus programas, y terminan produciendo
código ilegible. Afortunadamente, existen muchas
herramientas que ayudan a embellecer el código
fuente, como por ejemplo Uncrustify, [3] que fun-
ciona con lenguajes como C++ y sus derivados (C,
Java, C#, etc.).

// Calcula el Máximo Común Divisor
long mcd(long a,long b){long g=((a<0)?-a
:a);long r=((b<0)?-b:b);long tmp;//resto
do {tmp=r;r=g%r;// módulo en común
g=tmp;}while (0!=r);return g;}// mcd()

Es especialmente importante usar identificadores
significativos para nombrar las variables y objetos
del programa. Por eso, en lugar de "chuleta24" es
conveniente llamar "impuesto" al porcentaje que
se debe agregar al monto facturado: aunque el
primer identificador es jocoso, la sonrisa se borra
cuando haya que entender qué significa que la
"chuleta24" en el contexto de un "culantro"
queda multiplicada por el "cangrejo".

5. DATOS DE PRUEBA
Sin datos de prueba no hay calidad. La falibilidad
humana es inevitable: ningún programador puede

“VI Taller Internacional de Calidad en las Tecnologías de la Información y las Comunicaciones ”

Di Mare | “Conocimiento de Programación Mínimo Requerido para Construir Programas de Buena Calidad”



implementar sus programas sin cometer errores,
aunque sean muy pequeños. Por eso, la prueba de
programas inherente al proceso de su construcción.
Desafortunadamente, bastantes programadores
desechan las pruebas de sus programas por lo que,
cuando hay que modificarlos, es necesario recons-
truirlas nuevamente. Por eso, es importante que el
código de prueba de cualquier módulo sea conser-
vado para su reutilización posterior, cuando se mo-
difica un programa.
La forma más simple de prueba de programas se
logra probando, aisladamente, cada uno de sus
módulos. A esta estrategia se le conoce como
prueba unitaria (unit testing). Existen muchas biblio-
tecas especializadas en este tipo de pruebas. Algu-
nas muy conocidas son las derivadas de JUnit [4]
(Java Unit Testing), también conocidas como xUnit
[5].
Es debatible cuál es el mínimo requerido para ha-
cer pruebas [6], pero uno de los elementos primor-
diales de cualquier prueba es el verbo assert() [C
arcaico] o assertTrue()
[JUnit] que sirve para
determinar si su argumento es o no verdadero. Una
definición C++ mínima de esta importante herra-
mienta es la siguiente:
/// Macro para prueba unitaria de módulos
#define assertTrue(cond) do if (!(cond))\
{ std::cout << "error[" << __LINE__ \
<< "] " #cond << std::endl; } whi le (0)

Si la prueba falla, un mensaje se error es emitido
(en el flujo std::cout en este caso). Si la condición
es verdadera, nada queda grabado. De esta mane-
ra, solo cuando hay fallas el programa de prueba
produce algo (aunque sea paradójico, “nada” signi-
fica “todo funciona bien”).

assertTrue ( 1 == mcd(1,2) );
assertTrue ( 2*3*5 ==
mcd( 2*2*2*2 * 3*3 * 5*5, 2*3*5 )
);
assertTrue ( 30 == mcd( -3600,-30 ) );


Desde que fue inven