Está demostrado, se pierden muchas horas e importantes recursos debido al código mal escrito, bajando la productividad, produciendo fallos no controlados y disminuyendo la velocidad del desarrollo.
Queramos reconocerlo o no, está es la realidad que vivimos en el día a día.
Es muy normal que si te dedicas al desarrollo te suene la siguiente situación:
Llega una incidencia a nuestros sistemas, parece ser que una página web o informe esta produciendo un error. Nuestro supervisor nos asigna la incidencia y procedemos a revisar el código fuente de la página o programa. ¡horror! No hay ni un triste comentario, la justificación del código no existe, los nombre de variables son tan significativos como “kk”, “pepe1”, etc…
¿Te suena? Pues bien, generalmente este tipo de incidencias se producen más habitualmente de lo que podemos imaginar.
Algunas de las razones (nunca justificables) son las siguientes:
- Desarrolladores sin una guía clara.
- Falta de un manual de buenas practicas.
- Inexistencia de sistemas de calidad del software.
- Falta de tiempo.
Esta claro que se trata de un problema importante, pero muchos no son conscientes de ello. En particular lo he vivido este mismo fin de semana. En la actualidad estoy realizando un MOOC de HTML5 y en el foro del mismo se discutía sobre una valoración del código de una actividad, código que había sido valorado con un 5 dada su falta de justificación y legibilidad. Había compañeros que argumentaban que si el código funcionaba que importaba la legibilidad del mismo, otros por otra parte defendíamos el código limpio.
Como consecuencia de todo esto he comenzado a leer el libro Código Limpio y estoy convencido de que he de trabajar en esta línea ya que es lo correcto. Confesaré que hasta ahora no he sido completamente consciente de la importancia de este extremo, pero siempre estamos a tiempo de mejorar.
Tras leer unos cuantos artículos con excelentes razones para dedicar tiempo a generar buen código me quedo con las tres siguientes:
- Debe ser agradable de leer.
- Debe de ser fácilmente modificable por otro desarrollador.
- Debe de ser expresivo.
Veamos un poco más en detalle estas tres razones.
Debe ser agradable de leer
Tendríamos que poner la simplicidad como uno de nuestros principales objetivos a la hora de generar nuestro código. Al mismo tiempo tenemos que intentar que pueda ser fácilmente leíble, dandole un formato agradable de leer y dejando un código perfectamente justificado y tabulado.
Existen dos principios fáciles de recordar y muy potentes en si mismos:
KISS : Keep It Simple, Stupid! : Mantenerlo Simple, Estúpido!
Cuanto más simple más fácil de mantener después.
YAGNI : You Ain’t Gonna Need It : No lo vas a necesitar.
Simplifica al máximo al código siempre que la simplificación no dificulte la lectura.
Debe de ser fácilmente modificable por otro desarrollador
Tenemos que pensar que cuando codificamos lo estamos haciendo para otro desarrollador. Además, ese otro podemos ser nosotros mismos dentro de algunos meses o años. Así pues, no tenemos que ser egoístas y pensar en esos otros desarrolladores.
Facilitemos la lectura del código, incluyamos todos los comentarios que consideremos necesarios para facilitar su lectura, no dejemos partes del código que ya no se utilizan comentadas, estructuremos nuestro código usando funciones, etc.
Debe de ser expresivo
Es decir, utilicemos nombre de variables y funciones significativos y que sigan una nomenclatura estándar. Esto facilita la lectura del código y en muchas ocasiones hace que se autodocumente.
Utiliza nombres de variables que representen al objeto que almacenan. Crea nombre de funciones y procedimientos que representen la función o tarea que realizan. Estas dos simples reglas aumentarán la calidad de nuestro código sin realizar demasiado trabajo.
Más Información
Para ampliar información al respecto te aconsejo que veas este sencillo video sobre código limpio, está basado en el libro Código Limpio que aconsejo leer para iniciarse en este interesante mundo.
Don't Give up! 