Board Blog

Es una lista armada y recopilada por Ricardo Rodríguez en su blog:  http://oficinaproyectosinformatica.blogspot.com.ar/, más que interesante, ahi va la transcripción:

1. Inconsistencia en la denominación de variables:
   Independientemente de la notación que se use, se debe ser consistente, no solamente con el casing utilizado pero también a la hora de asignar normas. Por ejemplo, si se está enviando el “Número del cliente”, no debe nombrársele “nroCli” en un lado, “IDCliente” en otro y “NumCli” en otro lado. Cada versión pareciera estar utilizando una estructura de datos diferente. Este tipo de cosas dificulta el mantenimiento de aplicaciones.
2. Manejo de fechas y horas:
   Trate en lo posible de no hacer conversiones de fecha y hora usted mismo, en su lugar, utilice las funciones de fecha y hora que los principales lenguajes de programación poseen, los cuales le permiten a usted abstraerse de formatos tales como notación militar, notación de 12 horas, etc.
3. La locura de la interfaz de usuario:
   Constantemente surge una nueva idea, componente, widget o estilo de interfaz gráfica de usuario, de pronto, está en todas partes. Está bien mientras se trate sólo de presentación, pero cuando se trate de funcionalidad de interfaz de usuario es necesario ser cuidadoso. El uso de estos componentes o widgets puede resolver muchos problemas en el desarrollo, pero a la vez crear problemas a los usuarios, sobre todo cuando son dirigidos a una audiencia que no los entiende, resultando en una desmejora de la experiencia del usuario.
4. No revisar los logs:
   El autor, Justin James, nos cuenta que muchas se ha encontrado con programadores que buscan ayuda de otros para resolver errores sin ni siquiera haber comenzado por revisar los logs. Si no ha revisado los logs, como puede pretenderse encontrar el problema que necesita arreglarse.

   Situaciones similares se presentan cuando los desarrolladores no buscan otras maneras de encontrar mensajes de error. Por ejemplo, si su aplicación web no está reportando error pero existe JavasScript involucrado, es posible que exista algún error en dicho JavaScript. Si simplemente se revisa la consola JavaScript usando las herramientas que dispone Internet Explorer (IE), Chrome o Firefox, podría darse con el problema.

5. La dependencia excesiva de herramientas autocompletar:
   Hoy en día todos los IDE de múltiples lenguajes de programación poseen herramientas autocompletar, las cuales se encargan de completar partes de código y hacer sugerencias a medida que se escribe. Esta herramienta es muy buena, pero de vez en cuando puede ocasionar problemas cuando no se revisa bien y se selecciona el componente incorrecto simplemente porque está de primero en la lista o se parece al que se necesita. A pesar de usar autocompletar no debe bajarse la guardia y tomarse un tiempo extra para asegurar que se ha seleccionado la opción correcta.
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 Cacth:
   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.