Errores básicos que cometen los desarrolladores

En el post anterior se habló sobre buenas prácticas de desarrollo utilizando REST, para verlo hacer click aquí. En este post se explicará de forma general algunos errores comunes tanto para desarrollo en general como para desarrolladores en Java específicamente.

Malos comentarios en el código

Existen 2 tipos de desarrolladores que realizan mal este punto, los primeros son los que no documentan absolutamente nada y por esto no se sabe a ciencia cierta lo que hace su código hasta leerlo completo y los segundos son los que quieren documentar su código pero no saben como hacerlo y hacen lo peor que se puede hacer (Poner un comentario en cada línea de código) Veamos un ejemplo de este tipo de código:

// Método contains que recibe 2 parámetros un arreglo y un entero
public static boolean contains(int[] a, int b) {
	// Itera el arreglo a
	// Inicio del for
	for (int i : a) {
		// Valida si la variable i es igual a el parámetro b
		// Inicio del if
		if (i == b) {
			// Regresa verdadero
			return true;
		}
		// Fin del if
		// Fin del for
	}
	// Devuelve falso
	return false;
}

Los comentarios que describen línea a línea el código no son una buena documentación por lo siguiente:

• Se debe recordar que las personas que leerán el código son desarrolladores y también saben que return false; Significa que el método devuelve el valor falso.
• Al hacer este tipo de comentarios se debe leer el método completo para saber lo que hace y es lo mismo leer los comentarios que leer el código(Incluso pienso que sería más útil leer sólo el código).
• El código se vuelve más difícil a la vista para leer.

Entonces, ¿Cómo debo comentar mi código? Veamos a continuación el mismo código pero comentado de la forma correcta:

/**
 * Busca en el arreglo especificado el valor recibido iterandolo.
 * @param a Arreglo en el cuál se realizará la búsqueda
 * @param b Valor que se busca en el arreglo
 * @return <code>true</code> Si el valor <code>b</code> existe en el arreglo <code>a</code>.
 * <code>false</code> Si el valor <code>b</code> no existe en el arreglo <code>a</code>
 */
public static boolean contains(int[] a, int b) {
	for (int i : a) {
		if (i == b) {
			return true;
		}
	}
	return false;
}

Con esto se tiene una descripción clara de lo que hace el método, lo que recibe como parámetro y lo que devuelve. A demás, si se utiliza un IDE de desarrollo se agregará esta documentación al momento de auto completar el código como se muestra en la siguiente imagen:
Otras malas prácticas al momento de comentar código:

• Dejar código comentado «por si se llega a utilizar en el futuro»: Existen controladores de versiones donde si es necesario ver una versión anterior se puede hacer, no es necesario mantener una pieza de código por la vida completa del proyecto.
• Utilizar comentarios como un control de versiones

No utilizar verificadores de estilo de código

Existen varios tipos de indentaciones correctas y no hay problema con usar una u otra, lo que recomiendo en este punto es utilizar un plugin que verifique el estilo de código, ya que si un desarrollador acostumbra indentar su código de algún modo y otro desarrollador acostumbra hacerlo de otro, los dos pueden están en lo correcto pero lo ideal para mantener el orden en el proyecto es que el proyecto siga un solo estilo.

En Java existen plugins en Maven que ayudan a forzar a seguir un solo estilo de código en el proyecto, el más común es Apache Maven Checkstyle Plugin.

Comentar test unitarios para compilar el código

Crea test unitarios para los componentes desarrollados y NO los comentes, los test unitarios deben ejecutarse en cada compilación de forma exitosa, si comentas los tests unitarios para compilar de forma correcta significa que algo estas haciendo mal. Sigue los siguientes puntos para hacer test unitarios de forma correcta:

• No utilices el constructor para inicializar la prueba, utiliza las anotaciones de JUnit para esto.
• Nunca asumas el orden de ejecución de los tests unitarios, tu prueba debe ser independiente a las demás.
• Crea tests unitarios repetibles sin intervención humana, si tienes que borrar un registro en una base de datos para ejecutar el caso de prueba, lo estas haciendo mal.
• Nunca utilices codigo duro(hard code) en Maven existe una ruta llamada /src/test/resources la cual es el lugar ideal para colocar las configuraciones de tus pruebas.

Mal uso del controlador de versiones

Un desarrollador nuevo se nota en primera vista cuando vez su repositorio de código y ves alguno de los siguientes puntos:

• Archivos compilados en el controlador de versiones: subir a git(O cualquier otro controlador) los archivos compilados de sus proyectos, el controlador de versiones es para el código, no para los archivos ya compilados, haz buen uso del archivo .gitignore.
• Malos comentarios en commits : Colocar comentarios como «bug fixed» en commits que contienen cambios grandes, busca siempre dar una descripción clara sobre el cambio hecho en el repositorio.
• Trabajar sobre master: Trabaja siempre sobre ramas y manten en master la versión estable del código.
• Subir al repositorio trabajo incompleto: El repositorio debe contener piezas de código completas, si deseas subir poco a poco un requerimiento al repositorio, divídelo en módulos pequeños y sube el código al repositorio cada que un módulo esté completo.
• El código siempre debe compilar: Muchas veces por error se sube código al repositorio que no compila y rompe los builds, lo cuál provoca que cuando otros desarrolladores descarguen el código no se pueda construir. Utiliza herramientas de Continuous integration para evitar este problema(Más adelante se hablará con más detalle al respecto en otros posts).

No utilizar patrones de diseño y estándares de desarrollo

Es muy común la idea de los desarrolladores «Lo importante es que funcione» y esta frase es una de las principales fuentes de bugs y proyectos  inmantenibles. El uso de patrones de diseño no solo facilita el desarrollo de las aplicaciones sino que facilita la integración de un miembro nuevo al equipo, la escalabilidad del proyecto y sobre todo la seguridad de que lo que estas desarrollando lo estas desarrollando de forma correcta.

A continuación se presenta una lista de patrones de diseño comunes disponibles en el desarrollo de aplicaciones:

• Creational Design Patterns:
  • Factory Pattern
  • Abstract Factory Pattern
  • Singleton Pattern
  • Prototype Pattern
  • Builder Pattern.
  • etc
• Structural Design Pattern:
  • Adapter Pattern Bridge
  • Pattern Composite
  • Pattern Decorator
  • Pattern Facade
  • Pattern Flyweight
  • Pattern Proxy Pattern
  • etc
• Behavioral Design Pattern:
  • Chain Of Responsibility Pattern
  • Command Pattern
  • Interpreter Pattern
  • Iterator Pattern
  • Mediator Pattern
  • Memento Pattern Observer
  • Pattern State
  • Pattern Strategy
  • Pattern Template
  • Pattern Visitor Pattern
  • etc

Pobre manejo de errores

 Un error común y doloroso de muchos desarrolladores nuevos es que su manejo de excepciones es el siguiente:

catch( Exception e ) {}

Lo cual es una de las peores prácticas que puede cometer un desarrollador en cualquier lenguaje de programación ya que provoca problemas en la aplicación y dificulta la detección rápida de errores en la aplicación.

Hardcode

Una de las peores prácticas de programación que se pueden encontrar y la más inaceptable de todas, asignar valores a variables o configuraciones en lugar de tomarlos de una fuente externa para que el código funcione «mientras termino» y dejarlos hasta producción.

NOTA: Estas son solo algunas malas prácticas de desarrollo que debes evitar, sabemos que existen mil más, si tienes alguna que te gustaría compartir escríbela en la sección de comentarios.

Autor: Alejandro Agapito Bautista

Twitter: @raidentrance

Contacto:raidentrance@gmail.com