Malas Prácticas en Java EE. Parte II

1. Reinventar la Rueda

Una práctica que he detectado al revisar código de diversos sistemas es el reinventar una y otra vez la rueda. A manera de ilustración: implementar el ordenamiento de una lista de manera manual. Lo ideal era hacer que el POJO implemente Comparable y luego simplemente ejecutar un Collections.sort(). Este último no solo simplifica notoriamente las labores de programación; sino que además es un mecanismo ampliamente probado, estándar y optimizado.

Otro caso es implementar desde cero un Map, cuando se puede usar alguna de las clases ya provistas por Java.

El mensaje que le puedo dar a los programadores es que investiguen, usualmente van a encontrar una clase ya provista por Java o bien por alguno de los proyectos open source existentes. Y si tienes a cargo un equipo de trabajo, periódicamente revisa el código que escriben los programadores.

2. Usar técnicas obsoletas

Este caso es una derivación del primero; aquí los programadores buscan en Google como implementar una funcionalidad X y elijen la primera respuesta funcional que aparece. El problema está en que no observan la fecha de publicación de la solución. Algunas pueden remontarse a una década o más, y no consideran que era la solucion que existía en Java 1.3; pero ya en Java 8 seguramente hay una forma más simple y elegante de solucionar las cosas.

No olviden revisar la fecha de cada post que encuentran y de una manera analítica determinar si habrá alguna mejor manera de hacer las cosas. No siempre el copiar y pegar una solución es lo correcto.

• Iterando todos los archivos en una ruta en Java 1.4

  File base = new File(ROOT);
  File[] lFiles = base.listFiles();
  for (int i = 0; i < lFiles.length; i++) {
  if (!lFiles[i].isDirectory()) {
    //@ Do something
  }
  }
  

• El código equivalente en Java 1.8 con NIO

  Path path= Paths.get(ROOT);
  try {
  Files.walkFileTree(path, new SimpleFileVisitor<Path>(){
    @Override
    public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException {
      if(!attrs.isDirectory()){
        //@Do something....
      }
      return FileVisitResult.CONTINUE;
    }
  });
  } catch (IOException e) {
  // Logger y manejo de excepción
  }
  

3. Ausencia de Documentación

Documentar es una actividad que es enseñada desde los primeros cursos universitarios; pero que pocos programadores practican de manera consistente. No es raro encontrar código con decenas de miles de líneas sin la menor documentación. Esto es una pesadilla de mantenimiento; es fundamental ejercitar esta actividad de manera diaria. Cada vez que programen: documenten, siempre y sin excusas. Debe volverse un acto reflejo en su actividad profesional.

Pocas cosas son peores que dar mantenimiento a un sistema que no explica porque se hizo X método de una manera; o porque existen ciertas condicionales. No se pretende que se escriba una disertación del tema; pero si que sea comprensible para un tercero. Si tienes un equipo a cargo; has revisiones al azar. Si algo no esta documentado; que el programador que lo hizo lo documente de inmediato.

4. Obsolescencia de Conocimientos

Esta práctica va orientada a que muchos programadores no invierten tiempo y recursos en mantenerse al día. Java es un lenguaje que esta en constante evolución; los conocimientos que se tienen en Java 1.4 son diferentes a las nuevas maneras de hacer las cosas en Java 8. Lambdas, Stream API, try with resources; etc deben formar parte del vocabulario de los programadores. No solo conociendo su significado, sino comprendiendo a cabalidad en que situaciones se emplean. Si eres un programador de Java te puedo dar dos consejos:

• Certificate! Una cosa es decir que sabes Java y otra muy diferente demostrarlo! Cuando te certifiques serás miembro de una élite.

• Estudia! Nunca pares de estudiar y de aprender nuevas cosas en Java; recuerda que hace no mucho tiempo atras se programaba en Struts o JSP, lo harías hoy en día? Aunque te sorprenda, aún en 2015 he encontrado sistemas nuevos usando estándares definidos para Java 1.4.

5. Estándares Institucionales

Este es un corolario del punto previo. En muchas instituciones públicas o privadas se tienen definidos estándares de programación para Java. Eso es excelente; siempre y cuando sean actualizados periódicamente. He tenido que lidiar con empresas que tienen establecido un estándar para desarrollos Java que quedó congelado en el tiempo. Establecen lineamientos que eran propios de Java 1.4; pero que son obsoletos hoy en día y peor aún; se reusan a actualizarlos. No es sino por medio de una labor de convencimiento y exposición de la línea de evolución del lenguaje que acceden -en ocasiones de mala gana- a abrir un portillo para poder desarrollar aplicaciones Java EE 7.

Recuerden, Java evoluciona! y asi deben ir los estándares de la empresa.