Errores comunes de programación: Segunda Parte

Imagen de: Picasa Web Albums

Anterior a este artículo publicamos “5 errores comunes de programación”, original del blog “Software Engineer de Techrepublic.com, el cual se describían algunas prácticas de programación erróneas. Luego de los comentarios recibidos de la comunidad, hemos decidido publicar una segunda parte, tomando en consideración las sugerencias de algunos usuarios y otras fuentes de información consultadas.

En este artículo se exploran cinco prácticas de programación que pueden ser problemáticas, abarcando la codificación sin un análisis previo, estructura inadecuada de módulos, codificación directa de variables (“Hard Coding”), omitir el manejo de excepciones y no documentar los comentarios en el código.

Presentamos a continuación, la segunda parte de la serie sobre “Errores de programación comunes”.

Acerca de la primera parte de este artículo

En nuestra entrega anterior, se presentaron las siguientes malas prácticas de programación:

1. Inconsistencia en la denominación de variables.
2. Manejo de fechas y horas.
3. La locura de la interfaz de usuario.
4. No revisar los logs.
5. La dependencia excesiva de herramientas autocompletar. 

>>Ver artículo "5 errores de programación comunes"

Errores de programación comunes: Segunda parte

6.- Comenzar a escribir el código antes analizar lo que se va a hacer

Un error que suelen cometer, sobre todo los analistas programadores más novatos es el querer comenzar a codificar antes de siguiera entender la totalidad del problema. Hoy en día existe la tentación de depender en exceso de un IDE que ayude en el diseño y codificación, en caso de hacerlo, debe procederse con cuidado.

Lo expuesto, puede llevar a asumir la lógica de negocio o a entenderla de forma distinta a como fue solicitada, sobretodo en casos en los cuales no se tiene a alguien del área de negocio cercano a quien consultarle (el usuario está en otra locación, región o país).

En estas situaciones, es preferible realizar una revisión detallada con el negocio de la funcionalidad a desarrollar, solicitando las clarificaciones necesarias antes de escribir el código. Esto es independientemente de la metodología de desarrollo aplicada, tanto si es predictiva o ágil.

7.- No estructurar el código en módulos y funciones

El no estructurar la funcionalidad en múltiples módulos o funciones puede ocasionar problemas para entender el código y darle mantenimiento. Es recomendable estructurar funciones con la menor cantidad de funcionalidad posible para completar un propósito único, nada más y nada menos.

8.- Codificación directa (“Hard Coding”) de mensajes y configuraciones

La codificación directa de mensajes y parámetros de configuraciones puede ocasionar bastantes problemas de mantenimiento, pues en el caso de tener que cambiar un mensaje o parámetro, deberá revisarse todo el código, con la posibilidad que pueda omitirse alguno, alargando el tiempo para desarrollar dicho mantenimiento y ocasionando retrabajo. En su lugar, es preferible manejar un archivo o base de datos de configuración en el cual se asignen los mensajes y parámetros a variables, que luego sean utilizadas en las distintas funciones y módulos.

9.- No manejar excepciones utilizando Try Catch

Existen argumentos muy validos tanto a favor como en contra de usar sentencias Try y Catch en lugar de condicionales if y else para el manejo de excepciones. En todo caso, independientemente de la forma que se utilice, la funcionalidad debe manejar todas las excepciones, sin que queden algunas sin manejarse. El manejo de excepciones permite a un programa finalizar por error de forma controlada, y permite manejar ese error (Exepction Handling).

Por regla general, el Try Catch se usa cuando se espera que el camino normal del código proceda sin errores, a menos que ocurran situaciones realmente excepcionales, como por ejemplo que el servidor esté fuera de línea, alguna plataforma o aplicación con la que se interactúa esté fuera de línea, las credenciales de sesión estén vencidas, etc. El If y Else se utiliza para manejar excepciones realmente esperadas según la lógica del negocio, por ejemplo cuando un usuario accede a una función para la cual no tiene roles funcionales asignados.

El manejo de excepciones es útil para mostrar mensajes de error que sean funcionales para el usuario. No usarlo podría implicar que en su lugar se muestren mensajes de error de programa, con descripción técnica incluida. Asimismo, no usarlo puede dificultar el análisis de errores por parte de un equipo de soporte o Help Desk.

10.- Comentarios en código ausentes, erróneos o desactualizados

El no documentar comentarios puede limitar severamente las posibilidades futuras de mantenimiento de la aplicación, después de todo, el personal de desarrollo tiende a rotar entre proyectos y compañías. Todo el que ha tenido que pasar por hacerle mantenimiento a un código sin documentación y programas de código sabe que se tiende a caer en el ensayo y error.

Inclusive para un mismo analista programador, escribir un código sin documentarlo, pasar a otra tarea y después regresar, si no documento los comentarios se dificultan el rastreo de errores.

Asimismo, debe asegurarse que los comentarios sean adecuados al código de programa comentado (evitar copiar y pegar), en caso de modificación de funciones y módulos existentes los comentarios deben ser actualizados, indicando quien lo modificó y en qué fecha.

Conclusión

¿Y qué opina usted?, ¿Cuáles errores de programación comunes se ha encontrado?, ¿Cuáles patrones y antipatrones de programación considera debe aplicarse?, ¿Qué errores agregaría a esta lista?. Le invitamos a participar en el foro de discusión del blog de “La Oficina de Proyectos de Informática” (http://oficinaproyectosinformatica.blogspot.com) y a suscribirse al blog por los distintos canales, incluyendo lista de correo electrónico, al Twitter @PMOInformatica o al feed RSS del Blog.


<< Ir a Segunda Parte

>> Siguiente Artículo: Errores comunes en el desarrollo de Base de datos

Fuente consultada:

>> Geek Files. 12 common programming mistakes to avoid.

Otros artículos en “La Oficina de Proyectos de Informática”

Gerencia de Desarrollo de Software

>> 10 actividades críticas a incluir en todo plan de desarrollo de un software

>> 5 errores comunes de programación

>> Los pasos para resolver incidentes en el período de estabilización de un desarrollo de software

>> Ambientes de pruebas integrales de software: Buenas prácticas

>> Ambientes de desarrollo de software: Buenas prácticas

>> Algunas prácticas de desarrollo de aplicaciones web para asegurar calidad, mantenibilidad, escalabilidad y seguridad

>> Herramientas de software para gestión de proyectos de desarrollo ágil

>> Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)

>> Las preguntas que debe hacer al encargarse de un proyecto de Tecnología de Información (TI) en ejecución

Aspectos Generales

>> Habilidades interpersonales cada vez más demandadas en los profesionales de Tecnologías de Información

>> Las Habilidades y Conocimientos más buscados en el área de Tecnología de Información (TI)

>> Las reuniones de trabajo: más productividad, menos reuniones 

Gerencia de Proyectos

>> Como hacer el seguimiento de los riesgos en proyectos

>> Plantilla para la Gestión de Riesgos en proyectos: Actualización Octubre 2012