Introducción

Para todo desarrollador de software es importante poder compreder el código que escribió hace algun tiempo invirtiendo el mínimo esfuerzo en dicha tarea. En este punto intervienen los documentos generados durante la etapa de diseño en el ciclo de vida de la aplicación y la claridad con la que se haya escrito el código. Muchos programadores descuidan este último punto originando verdaderos quebraderos de cabeza durante la etapa de mantenimiento. No en vano, el 80% del coste de una aplicación queda centrado en esta etapa.

Por otra parte, la mayoría del software posee interface para comunicar con el usuario que en muchas ocasiones están sobrecargadas de gráficos y textos no relevantes para la situación, despistando al usuario y haciendo más difícil trabajar con el programa. En este artículo expondré distintos puntos acerca de como escribir código legible y diseñar interfaces de usuario agradables, centrándome en el lenguaje Java aunque se puede extrapolar a otros.


Escritura del programa

Muchos programadores, entre los que me incluyo yo, tenemos la tendencia a pensar un problema e intentar desarrollar una solución, sin pensar que alguien pudo haber pasado por la misma situación. Los patrones de diseño -desing patterns- proporcionan soluciones estándar a problemas del desarrollo de software. El objetivo de estos es proporcionar un conjunto de soluciones a situaciones cotidianas durante
la etapa de diseño e implantación de un programa. Además ahorra tiempo al no tener que idear una solución a un determinado problema.

La claridad del código es importante. Por ello es necesario que los programadores de un mismo equipo sigan unas pautas de diseño que facilitará la comunicación y aprendizaje por parte de otros desarrolladores. Hay que tener en cuenta que, a medida que crece un proyecto, se pueden incorporar más personas al equipo.

Las líneas de código no deben ser muy extensas, por lo general inferiores a 80 caracteres. En caso de necesitar más, se bajan a la siguiente línea. Podemos aprovechar un cierre de paréntesis o una coma etc…

Se deben emplear espacios o tabuladores para que se distingan con claridad los distintos bloques de sentencias. Es recomendable emplear espacios en blanco debído a las distintas interpretaciones que hacen los editores sobre las tabulaciones.

No debe existir más de una sentencia por línea: System.out.println(“texto”); a++;

Otro punto muy importante es comprobar que las entradas de información se corresponden con el dominio de datos que se espera. De no realizar estas comprobaciones podemos caer en graves errores de seguridad como los de desbordamiento de pila. Aunque en Java no es problema, en otros lenguajes como C++ debemos vigilar el rango de los índices en el acceso a elementos de estructuras en memoria.

Constantes, variables y clases

Si la clase pertenece a un paquete, package, este debe ser la primera sentencia. Tras esta se colocarán los import.

Las constantes se escriben en mayúsculas y emplean la palabra reservada final para mantener la condición de constante.

Los nombres de las clases comienzan con mayúscula. Si el nombre es compuesto de varias palabras, por lo general se escriben juntas y con el primer carácter en mayúscula –notación UpperCamelCase-.

Ejemplo: public class MyClase {…}

Las instancias de las clases, los objetos, comienzan con minúscula y en caso de estar compuesto de varias palabras, el resto comenzarán con mayúscula –notacion CamelCase-:

Ejemplo: public String myCadena;

Existen un orden a la hora de declarar las variables: En primer lugar se declaran las estáticas, seguidas de la públicas, protegidas y privadas.

El nombre de las variables y clases debe ser significativo, permitiendo tener una idea de su función con solo leerlo. Esto no siempre es posible, pero siempre es mejor dar un nombre cercano al objetivo que un nombre al azar.

Las variables siempre se debe inicializar si no queremos llevarnos sorpresas y excepciones.

Es recomendable no emplear las inner class, es decir, clases declaradas dentro de otra clase. En muchas ocasiones convergen en confusión debido a que se pasan por alto.

Comentarios

En Java tenemos dos tipos de comentarios: Los de JavaDoc y los de bloques y líneas de código sueltas. Es muy recomendable documentar cada uno de los métodos y variables relevantes de la clase. También es importante detallar el uso de cada constante. El comentario de la clase en general debería tener los siguientes campos:

  • Nombre del autor.
  • Fecha de creación.
  • Descripción breve de sus funciones.
  • Licencia bajo la que se ampara.
  • Historial de cambios, en los que se incluiría el nombre del autor de los cambios, la fecha y un comentario sobre los mismos.

Respecto a los comentarios de bloques y líneas sueltas, se debe ser preciso, y no sobrecomentar el código.

Aplicación e Interface de usuario

La interface de nuestra aplicación es la ventana al mundo del usuario. Es importante cuidar los detalles estéticos y ser precisos, porque lo que queremos es que el usuario se sienta cómodo con nuestro software. Existen una serie de pautas, estudiadas por psicologos, que ayudan a tener un entorno más agradable.

El espacio del texto y los gráficos no debería exceder el 40 % del formulario.

Se debe pedir solo la información necesaria.

Si el usuario realiza consultas, se debe mostrar lo relevante, o por lo menos, clasificar el contenido y dar mayor prioridad a aquello que se acerca a lo que el usuario realmente quiere. Viva la filosofía Google!!.

Los textos de los formularios deben ser claros y concisos.

Colocar cerca los elementos relacionados. Los datos importantes o de uso más frecuente deben de estar en primer lugar.

Es importante la consistencia visual: Cuando se diseña la interface de usuario, normalmente se piensa en una estructura general, conjunto de colores empleado…etc La interface debe ser intuitiva, designando de la misma forma a los componentes con la misma función y comportamiento a lo largo de los formularios. Esto minimiza el tiempo de aprendizaje.

Respecto a la aplicación en general, se debe partir de una aptitud de asistencia, es decir, proporcionar al usuario ayuda para realizar las tareas. En este ámbito son muy útiles los tooltips incorporados por la mayoría de los lenguajes de alto nivel actuales. Los asistentes, generalmente entra en conflicto con el usuario experimentado (ver el conflicto entre usuarios KDE y Gnome) de manera que es recomendable crear varios niveles de usuario, abarcando en cada uno distintas formas de interactuar con la aplicación. Cada uno de ellos tendrá un grado de abstracción que determina la facilidad de trabajo.

La aplicación debe ser intuitiva: El acceso a las distintas funciones debe ser previsible. Esto crea sensación de progreso y permite al usuario experimentar con la aplicación aumentando el grado de soltura con la misma.

Se debe minimizar los errores producidos por el usuario e intentar proporcionar caminos reversibles a sus acciones.

Esto ha sido todo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: