Mantenibilidad en proyectos

Esta semana, me he visto obligado a trabajar en uno de esos proyectos zombie, donde da igual las veces que acabes con ellos porque siempre vuelven para perseguirte. En algunos casos como el que me ocupa hoy, el código es ajeno y no puedo contactar con el ***** que lo engendró. Y es que existe una práctica muy común en las ingenierías (sobretodo en empresas pequeñas) donde se tiende a subestimar los recursos necesarios para llevar a cabo un proyecto (en muchas ocasiones esta sub-estimación es forzosa, claro), pero a medida que la empresa crece, las malas costumbres suelen persistir.

El caso es que lidiar con ese código infame me ha permitido recordar ciertas rutinas consideradas “buenas prácticas” en la universidad, pero que yo considero reglas inquebrantables cuando nos movemos en entornos más profesionales.

Leyes de la mantenibilidad de código:

  1. Comentar sí, pero sin pasarse. Citando a Steve McConnell (autor de grandes biblias como  “Code Complete”) “Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’”
  2. Modularidad. Si un método, función o rutina se va a alargar tanto que se puede perder el hilo al leerla, es buena idea separarla en varias. En general, no se me ocurren casos donde un método deba ocupar más de 200 líneas. Aumentar la modularidad, ayuda también a cumplir la siguiente regla.
  3. Límite de parámetros. No generar rutinas donde la cabecera sea ilegible. Algunos autores afirma que 7 debería de ser el número máximo de parámetros por el límite a la capacidad cognitiva que enunció Miller (1956).
  4. Tamaño de línea. Se considera que superar la longitud de 80 columnas por fila es una falta de estilo. Esto es debido a que 80 son las columnas que caben en un folio impreso. Además, facilita la lectura.
  5. Notificación al usuario. Cuando se notifique de algún error, o evento de traza para debug, se debe aportar la información justa y en ningún caso alarmar al usuario. Caso de estudio la BSOD de Microsoft.
  6. Tiempos de vida cortos. Las variables se declaran cuando van a utilizarse, y se destruyen lo antes posible. De forma que su ciclo de vida sea lo más corto (en líneas de código) posible. Nada de declarar al inicio del programa todas las variables necesarias.
  7. Excepciones. Catch vacío es mal. Distintos catches para distintas excepciones dentro del mismo try es bien.
  8. Análisis. Dedicar tiempo de análisis al inicio puede ahorrar muchas horas después. Es bueno diseñar el software con todas las armas que nos dé el lenguaje concreto para evitar pérdidas de tiempo más adelante. Desglose en clases (en POO), funciones, rutinas…
  9. No abusar de las líneas en blanco. Un número de líneas en blanco elevado (mayor al 10-20% del código) es absolutamente contraproducente. Dificulta la lectura y reduce la cohesión del código.
  10. Documentación. Quizás la parte más importante. Se suele aceptar como motivo de aplauso y regocijo general encontrar un software con documentación, tanto generada automáticamente (como doxygen, por ejemplo) como redactada por el propio programador (manuales, tutoriales, guías, screenshots …). El hecho de utilizar herramientas para documentar ya hace que se deba seguir cierto protocolo en los comentarios (Javadoc, por ejemplo), lo que enriquece el estilo. Escuchar que tal proyecto no necesita documentación (sea cual sea la excusa) es razón suficiente para abandonar una conversación.

Bueno, esto es lo que para mí (y muchos otros autores) es fundamental a la hora de desarrollar algo que el simple hecho de contemplarlo no produzca una sensación de querer matar morir. Me despido con una cita muy acorde con el tema:

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”
– Martin Golding

Voy a seguir a mi tarea de mantener este engendro. Entre tanto, puede que me sirva de ayuda un poco de relajación. Os paso el link que voy a utilizar para ello.

Enlaces:

Compartir: Enlaces a sitios sociales.
  • BarraPunto
  • email
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Meneame
  • Twitter

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *