El documento proporciona numerosos consejos prácticos para el análisis, diseño e implementación de sistemas de información. Algunos de los consejos clave incluyen documentar el código de manera exhaustiva, usar nombres descriptivos, minimizar el uso de variables globales, probar módulos de forma independiente, y actualizar constantemente los conocimientos y herramientas de desarrollo. El autor enfatiza la importancia de aprender de los errores propios y de otros programadores experimentados.

1. Consejos prácticos a la hora de analizar, diseñar e implementar sistemas de información
Ficha técnica del artículo
Nombre Consejos a la hora de programar computadoras
Autor Luis Eduardo Peláez Valencia
Ingeniero de sistemas
Miembro ACIS desde 1998
Fecha 25 de febrero de 2000
Corrección
Después de varios años de experiencia, muchos errores cometidos en el desarrollo de sistemas de
información, leer autores como Tanembaum, Wirth, McGuire, Ritchie, Rumbauch, etc. Todos autores
de libros dirigidos a la implementación de sistemas informáticos y luego de ver a mis estudiantes
romper las reglas de programación antes de conocerlas, me atrevo a escribir algunos consejos de
programación de sistemas de información que en algún momento nos podrán servir para evitar
cometer los errores que ya cometí y que en algún momento también Uds. Los lectores de este artículo
lo podrán hacer.
Algunos fueron tomados de los libros de autores mencionados anteriormente y los considero
indispensables para que los estudiantes, aunque no los vean en un libro, los tengan en cuenta.
• Se debe buscar la forma correcta de hacer programas. Tenga en cuenta que la mejor forma
de programar, no siempre es la forma correcta. Tiene mas que ver con buenos hábitos de
programación.
• Puede ser que Juan es mejor programando que Luis, y Luis es mejor que Jose. Todo porque
Juan hace programas mas grandes que Luis y asi sucesivamente. Si vemos el código fuente de
cada uno quizá resulte que el de Jose es un código mas limpio, estructurado y documentado
que el de los demás. De esta forma Jose podra utilizar su programa dentro de unos años para
modificarlo y le resultará mas fácil que a los otros. Además para otros programadores sería
mas fácil trabajar con Jose que con los otros. Finalmente si Ud. No puede entender el código
de un programa que hizo, entonces quien lo hará?
• No se puede tratar de escribir la versión final de un programa desde el primer momento que
se escribe el código. Siempre habrá cosas nuevas y momentos para cambiar el software. No
trate de hacerlo todo al tiempo, porque nunca va a terminar su sistema de información.
• No se debe dar nada por supuesto. Los usuarios pueden pulsar ENTER cuando deberían
pulsar ESCAPE.
• Los programadores que no permiten anticipar “teclazos” del usuario a la respuesta del sistema,
deberían ser condenados a usar su propio sistema.
• Lo último que se le hace a un programa es la interfaz de usuario, pero esto no quiere decir
que no sea uno de los elementos mas importantes del programa. Es incluso el elemento por el
que los usuarios valoran los programas.
• No se debe utilizar código de otros programadores que no se entienda del todo.
• Se debe usar nombres descriptivos para los objetos, las funciones, las variables, los archivos,
las bases de datos, las tablas, constantes, etc. De esta forma siempre darán una pista de lo
que hacen.
• Se debe usar el menor número posible de variables publicas y/o globales. Siempre que las
use, se deben declarar todas juntas o encerrarlas en una función o procedimiento. De esta
Luis Eduardo Peláez Valencia – Ingeniero de Sistemas - MSCD

2. Consejos prácticos a la hora de analizar, diseñar e implementar sistemas de información
forma siempre se sabe donde buscarlas.
• En los bucles se debe tratan de utilizar variables locales y/o privadas con nombres que no
tengan nada que ver con las variables globales.
• Las variables son eso “VARIABLES”, y cuando deberían tener un valor, a veces tienen otro,
hágale una prueba de escritorio.
• Utilice las técnicas de prueba del software: La c aja blanca, la caja negra, estructuras de
control.
• Los programas modulares siempre funcionan de forma independiente, hágale una prueba de
integración a sus módulos para garantizar que funcionan en unión.
• Se debe controlar muy bien la memoria que utiliza, se debe usar solo la necesaria y liberarla al
terminar un programa.
• Cuando su programa cambie alguna propiedad del sistema operativo o plataforma que utilice,
se debe volver a dejar como estaba. Un programa “Educado” es mas apreciado por los
usuarios.
• Si pasa mucho rato buscando un error y no lo encuentra, seguramente esta en otra parte del
código.
• Mucho cuidado con los caracteres que no son imprimibles, por error se puede digitar uno de
estos, y ese error si que no se va a encontrar.
• Cuando tenga un error en el nombre de un elemento del programa, verifique primero si en
lugar de escribir una O (o mayúscula), se escribió un 0 (Cero).
• Los errores no desaparecen solos, ni con el tiempo, ni con la ayuda de los usuarios.
• Un programador avanzado no tiene menos errores que un principiante. Solo los encuentra y
los corrige más rápido.
• Si después de horas de programación, en lugar de avanzar, retrocede. Apague el equipo e
inicie el día siguiente.
• Se debe documentar, documentar y documentar. De esta forma se entiende mejor, mejor y
mejor.
• Antes de empezar hoy dele un vistazo a lo que terminó ayer.
• Tener un “montón” de gente trabajando en el mismo proyecto, no los convierte en un equipo.
• Si se puede imaginar un proceso lógico, se puede implementar a través de una herramienta de
programación.
• Si esta empezando con un tema nuevo, primero siga instrucciones, no asuma nada, y aprenda
de sus errores.
• Si se le advierte que a cometer determinado error, es el colmo que efectivamente lo cometa.
Tenga mucho cuidado.
• Tenga siempre presente las tablas de decisión, de verdad, operadores lógicos, matemáticos,
relacionales y ante todo su jerarquía.
• Si no tiene la capacidad de tolerar un error en un módulo de programa, no va a poder con los
miles que se le presentarán.
• Cuando tenga un error, no trate de cambiar el proceso sin antes conocer la razón del error.
• Escoja una nomenclatura en su equipo de trabajo para dar nombres a los elementos del
programa.
• Si vemos que en nuestra aplicación hay código que se repite mucho, lo mejor será ponerlo
dentro de un procedimiento o de una función para facilitar su uso y hacer el código más
inteligible.
• Usar Constantes para valores que se vayan a usar mucho en el código.
• Dar tipo a las variables. Es muy recomendable, pues así no se malgasta memoria, al reservarse
justo lo que el tipo de la variable necesita.
Luis Eduardo Peláez Valencia – Ingeniero de Sistemas - MSCD

3. Consejos prácticos a la hora de analizar, diseñar e implementar sistemas de información
• No abusar de muchas sentencias if anidadas, pues se incrementa la complejidad del código y
puede que al final no obtengamos el resultado esperado.
• El buen estudiante hace más de lo que el maestro le pide.
• Programar es como un músculo, se debe ejercitar para que se desarrolle
• Finalmente recomiendo que se dedique 200 horas por semestre a el
estudio de sistemas de información y a la programación. Si hace 200
programas mejor. Si consulta ingenieros, tecnólogos, programadores
experimentados, maestros, alumnos avanzados, foros en internet,
revistas y manuales, sera mucho mas fácil.
Con estos consejos y una actualización constante de conocimientos y
herramientas de desarrollo, seguramente tendremos un poco de éxito en
nuestro análisis, diseño e implementación de sistemas de información.
Luis Eduardo Peláez Valencia – Ingeniero de Sistemas - MSCD