Malas Prácticas en la Programación

La mayoría de los posts que publica el equipo de MoztroDev - especialmente aquellos tutoriales dedicados a programación-, siempre han tenido la finalidad, además de enseñar, de cultivar en nuestros desarrollos el uso de buenas prácticas o, al menos, evitar las malas. Pueden ser desde cosas tan simples como el hecho de no incluir código duro en nuestro programa, hasta técnicas más avanzadas como el uso de patrones de diseño. Y si pensabas que con aprender a programar era suficiente, ¡think again! Veamos algunas de las malas prácticas más molestas tras el salto...

Si bien estamos de acuerdo en que la programación es un proceso creativo, ingenioso, desafiante y para muchos divertido, en ocasiones puede llegar a ser molesto (sobre todo si se trabaja en equipo) toparnos con código ajeno ilegible, códigos "chorizo", nombres de métodos y variables nada identificables. Imaginemos que somos parte de un grupo de desarrollo, y de repente un miembro del equipo decide renunciar y tu eres la persona designada (Idónea es la palabra que usan los Jefes de proyecto, Sacrificada diría yo) a mantener los proyectos desarrollados por el integrante ahora ausente. Y al revisar sus códigos, !Oh sorpresa! Nos encontramos con algunas de las siguientes cosas:

• Mala denominación de variables: Nos damos cuenta que nuestro ex-compañero está en pro del ahorro de memoria, y ha decidido nombrar todas y cada una de sus variables como a,b,a1,a2, etc. sin especificar para que serán utilizadas y peor aún te encuentras un método llamado validar, y piensas "ok, validar QUE!!!", estoy de acuerdo en que si tenemos un poquito de noción al leer el código podamos identificar que hace cada parte, pero seamos honestos, esto no siempre ocurre. Una de las recomendaciones es nombrar, sin explayarnos tanto, nuestras variables y métodos con alguna descripción de lo que realmente hacen, por ejemplo:
• validar_credito_cliente(Cliente) ó validarCreditoCliente(Cliente), para validar que el cliente que enviamos como parámetro tenga credito en nuestro negocio.
• consultar_clientes_por_Zona(Cliente) ó consultarClientePorId(Cliente), los métodos de consulta deberían de auto explicar si se requiere hacer una consulta completa o una específica.

• Comentarios inútiles o ausencia de comentarios: Si bien el problema anterior puede ser evitado mediante comentarios en cada una de las partes de nuestro código, muchas veces los programadores redactan estos comentarios para beneficio propio y no para explicar la función del código, por lo que no es extraño toparnos con comentarios como "generó una incidencia, revisar posteriormente" y nosotros con cara de WTF!. O lo que muchas veces es peor, es encontrarnos con métodos comentados, no sabemos para que lo utilizo ni porque decidió dejarlo comentado en vez de eliminarlo. Una alternativa es, sin meternos muy a fondo en cuestiones de javadoc, poner en los comentarios la función principal del método (por ejemplo, "Método que consulta un cliente en especifico mediante su Id"), los parámetros que recibe, el tipo de valor devuelto, etc.

• Clases gordas: Quizás una de las peores prácticas que pueden existir (sino es que la peor) es encontrarnos con clases gordas o con "códigos chorizo". Para los que no estén familiarizados con estos términos una clase gorda es una clase en demasía extensa que contiene TODA la lógica del programa, el programador decidió meter en un solo archivo todas las variables, atributos, objetos, métodos, accesos a datos, reglas de negocio y demás. Ahora imagínate tener que modificar una funcionalidad, tendrías que buscar entre todo el archivo la parte de código dedicada a eso ¡Tardarías demasiado! La solución es bastante obvia: la programación en capas y el uso de arquitecturas de desarrollo tales como MVC, MVP o MVVM o simplemente definir una arquitectura que te acomode y te permita trabajar ordenadamente y delegar responsabilidades. Esto es la base del trabajo en equipo y todos los equipos de desarrollo en el mundo trabajan de ésta manera. Les prometo un tutorial de arquitecturas de programación apenas tenga el tiempo suficiente.

• Botón mágico: Si estamos revisando la interfaz gráfica de una aplicación, y quisiéramos revisar que es lo que hace un determinado botón lo mas lógico sería ver a que método invoca dicho botón. Pero cuando queremos hacer esto nos topamos con que ¡El código esta dentro de los eventos del botón! (Abstracción nivel PM) Esto es malo por lo siguiente, si trabajamos en equipo, la tarea de Diseño de interfaces gráficas se delega a otros miembros del grupo y este proceso, al igual que los otros, es una constante de cambios en la interfaz por lo que si tenemos el código dentro del evento onclick de boton1, puede que boton1 ya no siga con vida al siguiente día y lo hayan decidido cambiar por boton2, y tendriamos que volver a poner todo el código dentro del nuevo evento y así cada vez que se modifique esa parte de la interfaz. Además de que no es bien visto.

• Poltergeist: Digamos que ya aprendieron a programar por capas, y se acomodaron a una arquitectura ajena o definida por ustedes mismos, pero hay que tener la precaución de que todas nuestras capas son realmente útiles y no se conviertan en poltergeists. Para los que no sepan que es un poltergeist les recomiendo primero vean la trilogía de Poltegeist. Bueno, ahora que ya se han visto las 3 películas y se han llevado uno que otro sustito regresemos a lo nuestro. En programación, llamamos poltergeist a las capas y/o a los métodos que únicamente sirven para pasar la información a un tercer objeto,lo que los vuelve realmente innecesarios ya que bien podríamos pasar directamente la información sin tener que pasar por él y además nos ocupa espacio en memoria y en nuestra arquitectura.

• No manejar excepciones: Aquí podemos entrar un poco en polémica acerca del uso de Try... Catch, ya que en muchos lados de la web existe gente con argumentos válidos de si usar o no este tipo de sentencias sobre condicionales IF. Si bien, el hecho de no controlar excepciones es más que una mala práctica, sino que definen la calidad de nuestra aplicación ante situaciones inesperadas. No pienso que haya que elegir entre utilizar una sentencia u otra, mas bien pienso que se pueden utilizar para situaciones diferentes. El Try...Catch atrapará cualquier tipo de error cuando esperamos que nuestro código transcurra normalmente, entre las excepciones pueden ocurrir un fallo en la conexión con el servidor, logueos erróneos, conversión de tipos, etc. En cambio las condicionales IF se utilizan para prevenir los errores esperados, por ejemplo cuando determinado usuario no tiene los permisos para acceder a cierto módulo. El uso de uno y otro se puede ir perfeccionando con la experiencia.

• Código sin Indentación: Si bien no eres de las personas que les guste estar comentado cada una de las partes de su código, deberías considerar tener una buena indentación. La indentación es lo que nos permite mediante tabulaciones definir diferentes niveles en nuestro código:  

En la imagen de arriba, el primer método tiene el código indentado y el segundo no. La indentación hace nuestro código mas legible y lo vuelve autoexplicativo (esto con ayuda de una correcta denominación de variables y métodos). Lenguajes de programación como Python utilizan la indentación para definir el orden de los procesos a ejecutar.

Estas son todas las malas prácticas de las que hablaremos hoy, considero que son las más conocidas (¡Y utilizadas!), si quieren ver una lista bastante completa de malas prácticas visiten el apartado de wikipedia aqui, o si piensan que obvie alguna pueden dejarla en los comentarios.

Esto es todo por ahora. Y tú ¿Cuál de estas malas prácticas has cometido?

¡Saludos!