Programando al programador

By: Mario Alejandro Montoya C.

Abstract: ¿En casa de herrero cuchara de palo? Es hora de programar al programador!

Es bien irónico que entre los programadores (especialmente aquellos que trabajan solos/equipos pequeños) se note un nivel alto de trabajo “manual” y repetitivo. Que raro, porque los que estamos en esto es por nuestra habilidad en convertir procesos manuales y repetitivos en software eficiente.

Más irónico aun, el hecho de que nos interese bastante mejores técnicas de programación que promueven la reducción del código (como la Programación Orientada a Objetos, la basada en componentes, etc...) y nos emocione las nuevas herramientas y tecnologías, que como siempre dice el eslogan “harán más sencillo tu trabajo” “podrás hacer más cosas, más rápido” y que se puede decir del RAD - desarrollo rápido de aplicaciones - ? ¿Rápido? Realmente parece una broma.... Y que se puede decir de aquellos que hablan interminablemente acerca de como sacarle, este, un milisegundo menos a una operación de su programa y pasar de algoritmos O(n) a O(log(n)) o lo que sea que signifique eso... para que? Igual les va a tomar meses/años sacarlo a la calle....

La cosa es que de poco sirven las nuevas y mejores herramientas, tecnologías o lo que sea, si el programador que esta detrás de ellas, simplemente, no organiza bien su forma de trabajar.

Es como ser un mecánico... se puede tener el taladro más rápido del mundo pero con las partes del motor regadas confusamente por todos lados y sin un plan de trabajo, simplemente le tomará mucho tiempo. De hecho pienso que no me gustaría que me arreglara el auto.

Es tiempo entonces, de programar al programador. De darle un entorno de trabajo, un método, herramientas.... de hacer un trabajo profesional.

Y ¿saben?, Delphi es un entorno de desarrollo profesional, que tiene incluido varias herramientas y que se integra con otras para ser más productivos.

Piense un momento: Si todos los mecánicos del mundo poseyeran las mismas herramientas y la misma experiencia, que podría diferenciar a unos de otros? Seguro que seria que tan efectivamente usan esa experiencia y esas herramientas.

    Tomando el camino

La excusa por defecto: No tengo tiempo, no se como. Si no sabes, cambia de trabajo, porque a un programador le pagan por saber... usar google. Tiempo? Como no se va uno a quejar si tiene el taller vuelto una zona de desastre! Claaaroooo que va tomar tiempo, pero esta vez, es uno bien invertido. Para un equipo de desarrollo pequeño no le debe tomar mas de un mes implementar lo que aqui se expone.

Para lograr tener un “taller” de programación no se requiere mucho dinero. De hecho, muchas herramientas se consiguen de forma gratuita. Otras están incluidas con Delphi (Dunit, StartTeam, Caliber). No existe NINGUNA barrera real para que hasta el más novato y solitario programador pueda tener su propio “taller”, de la misma manera que cualquiera puede empezar a tener su taller de autos simplemente cambiando llantas.

Vamos a alejarnos un poco del código y a ver las actividades típicas que toman mucho tiempo, son repetitivas, propensas a fallas, etc... Estas son:

  • Manejo del código fuente y los cambios que se le hacen
  • Detección de errores
  • Verificación de que los errores están solucionados
  • Generación de instaladores

    Nivel Básico : Lo que minimamente hay que hacer...

    1.Organizar archivos

¿Recuerda las partes regadas del motor? así son muchos programadores con sus archivos... están por todos lados sin ningún orden aparente u obvio.

Aunque no se puede dar una regla definitiva ya que dependerá del tipo de proyecto y su tamaño, al menos debería organizarse así:

  • El directorio raíz incluye los archivos de proyecto...
  • Un directorio donde poner los archivos ejecutables/paquetes/librerías (ej: Bin). Es importante que los ejecutables/dlls esten en un directorio separado del código fuente y de archivos temporales como los .DCU.
  • Un directorio donde poner los archivos compilados (como los .dcu)
  • Un directorio por cada subproyecto
  • Un directorio por cada tipo de archivos (ej: Formas, Clases, Recursos, etc...)

Para un programador con pocos proyectos, esta podría ser una manera de hacerlo:

Proyectos

-------Instaladores

--------------Instalador Proyecto 1

--------------Instalador Proyecto 2

-------Recursos compartidos

--------------imágenes

--------------cursores

--------------iconos

-------Comunes

--------------Clases

--------------Formularios

--------------etc...

-------Temp

--------------dcu

-------Proyecto 1

--------------Bin

--------------Formas

--------------Clases

--------------Recursos

--------------Otros

--------------Ayudas

-------Proyecto 2

Para quienes tienen proyectos más complejos algo así:

-------Proyecto 1

--------------Win32

---------------------Cliente

----------------------------Bin

----------------------------Formas

----------------------------Clases

----------------------------Recursos

---------------------Servidor

----------------------------Clases

--------------NET

--------------Web

--------------Ayudas

--------------Comunes

O como tenga sentido de acuerdo a las características de cada empresa o programador.

Una vez existe una estructura de archivos razonablemente lógica (no tiene porque ser totalmente rígida) se facilita lo siguiente:

    2.Usar un control de código fuente

Un elemento CRUCIAL para el resto de actividades que ayudan a automatizar las tareas de un programador, es usar un control de código fuente. Este permite llevar un control de las variaciones en el tiempo que se han hecho al código, de las versiones de cada archivo, las razones de los cambios hechos, quien realizo el cambio y cuando; ademas permite “viajar” en el tiempo dentro del proyecto... lo cual es muy útil cuando el proyecto esta avanzado y se nota que la versión 1.0 funcionaba bien pero que algo entre esta y la versión 1.5 causo un problema... las herramientas de control de código permiten ver las diferencias y aislar rápidamente las lineas de código que aportan los cambios.

Este punto, simplemente no se puede discutir. ¿Sientes que en tu cabeza empiezan a salir argumentos en contra de tener control de código fuente? ¿Crees que es más listo copiar y pegar archivos? Copiar y pegar? Eso es para programadores novatos de Visual Basic. Nosotros tenemos mas orgullo. Acalla esos temores. De todo, al menos logra este objetivo.

Existen muchas herramientas disponibles. Personalmente uso Subversion / Tortoise SVN, aunque existen muchas otras como Jedi CVS, StartTeam (incluido en las versiones superiores de Delphi 8+) y otros.

Dentro del control de código fuente se debe colocar TODO lo que permite que el programa sea compilado y que permita generar la instalación (ej: Archivos de código, recursos – como imágenes -, referencias a archivos compilados externos, si se referencia de forma directa) y poner afuera todo lo que sea producto del proyecto, como los ejecutables, los archivos compilados como los .dcu, archivos específicos del entorno de desarrollo, etc...

    3.Automatizar la depuración

Un programa es un conjunto de errores que, tal vez, alguna vez hará lo que se le dijo – pero no necesariamente, lo que se quería”.

Ya que gran parte del tiempo en un desarrollo se gasta depurando, es bueno buscar maneras de automatizar esa parte del trabajo.

Una manera que ha cobrado fuerza son los “unit test”, que es simplemente, escribir un programa que verifica la correcta funcionalidad de otro. Es ideal para el código no visual, que hace cálculos, que verifica datos, lógica de negocios, etc...

La ventaja de usar un sistema automatizado de pruebas es que permiten verificar MUY rápidamente si un cambio realizado a tenido efectos colaterales en otras partes de código, ayuda a escribir código mas robusto (ya que se enfoca el esfuerzo no en liberar código, sino en hacer que el código cumplan con las especificaciones) y mucho mas.

Además es muy fácil de hacerlo y desde Delphi 2005 en adelante la excelente herramienta Dunit se encuentra integrada y también se puede descargar gratuitamente para otras versiones.

    4.Tener una lista de tareas

Ya sea usando la funcionalidad de TODO de Delphi o en una herramienta separada o un archivo de Excel o lo que sea, tener una lista de actividades es importante para mantener centrada la mente del programador. Ademas, ayuda a estimar los tiempos de forma mas fiable y permite prever con anterioridad lo que hay que hacer.

Hay muchos programas de manejo de bugs disponibles y Delphi en sus versiones superiores incluye uno con StarTeam. Personalmente uso Gemini.

    5.Guardar los errores y su solución

Nada mas molesto que un problema pase una y otra vez, y aunque sepamos que ese error YA lo habíamos visto, se nos olvido donde y como se soluciona... o el cliente reporta de forma continua un determinado problema y debemos, otra vez, explicarlo todo. Llevar una lista de los errores, requerimientos, quejas y sus SOLUCIONES es la única forma decente de hacer las cosas.

    6.Resolver primero los problemas, luego hacer código nuevo

Los dos pasos anteriores obligan a tener una política clara: Sabiendo que problemas existen, que cosas hay que hacer y que requerimientos se deben cumplir, simplemente:

1- Arreglar los errores, de los mas graves a los menos graves. UNA VEZ SE RESUELVAN TODOS LOS ERRORES DE LA LISTA (¿cual? La lista que hiciste en el paso anterior, pequeño saltamontes).

Resolver aquí significa tomar una de 3 decisiones:

  • Se corrige el problema
  • No es posible corregir el problema, entonces especificar porque no se puede corregir (ej: No se puede reproducir el problema)
  • Se podría corregir el problema, pero tomaría demasiado tiempo y su permanencia no afecta seriamente el uso del programa (ej: El programa falla si se instala sobre Windows XP con idioma Japones. No hay clientes japoneses así que más da!). Una vez más, se debe escribir la razón del por que no se soluciona.

2- Satisfacer la lista de requerimientos... algún día hay que hacerlo, no?

3- Cualquier otra cosa, si queda tiempo... Pero mejor no. El tiempo que te queda dedicalo a tu familia. En serio.

Ahora, tenemos nuestro “taller” de código organizado de forma decente, y sin requerir un esfuerzo enorme o demasiado tiempo/dinero.

El programador/equipo debería practicar un tiempo en este nivel hasta que se sientan cómodos para poder beneficiarse plenamente del siguiente nivel:

    Nivel Avanzado : Integrando todo

Digamos que todo lo anterior es la forma “artesanal” de tener nuestro taller de código. Pero podemos ir un poco más allá:

    1.Pruebas finales.

Se debe hacer todo esfuerzo por darle las pruebas finales. “Pruebas finales” es mi manera culta de decir “Pruebas fuera de la matrix, en el mundo real”. En todo caso, debería de existir una lista de chequeo, con las cosas que se deben probar.

Esto podría incluir:

  • Pruebas de parte del programador encargado (entrar al programa, abrir las opciones, etc...). Con la herramienta de control de código fuente se pueden saber cuales son los cambios y concentrarse solo en estos a la hora de hacer pruebas. Obviamente se correría todas las pruebas de unidad primero.
  • Pruebas de parte de un “usuario final”. En este caso podría ser alguien encargado de hacer pruebas, un testeador. Como su mamá, que seguro lo quiere y se aguanta su afición a los computadores aunque preferiria que estuviera buscando una muchacha y sentará cabeza.
  • Por todo lo que quiera, debe hacerlo un “usuario final”. Un programador es por definición totalmente incapaz de hacerlo correctamente, así que convenza a su mamá de que le ayude, ok?
  • Pruebas de desempeño... Por ejemplo, para un sitio Web puede incluir ejecutar una serie de scripts que verifican como se desempeña y como compara contra los resultados anteriores (ej: Cuantas paginas por minuto puede producir, cuantos usuarios concurrentes, etc....)
  • Pruebas de instalación. Como funciona en diferentes versiones del sistema operativo
  • Otras

Es muy benéfico usar un producto como VMWare para ejecutar estas pruebas en un ambiente aislado, y que se le pueda dar “Ctrl-Z” a todo el sistema para poder asegurarse que todo empieza de nuevo la próxima vez. Puedes tener corriendo en tu propio computador varios computadores “virtuales” y simular una red, por ejemplo, entre un Win98, Win2003, Linux y Mac Os X.

    2.Reorganizar el código (Refactoring)

En la medida que vamos organizando nuestro taller, mientras escribimos una prueba automática, buscamos la fuente de un error y todo lo demás, veremos que nuestro código puede estar desorganizado, ilegible, confuso. Es tiempo de ir organizando internamente:

Separar el código visual (ej: Lo que esta en un formulario) de lo que no es visual (ej: Cálculos, conexión y manipulación de datos) para simplificar el mantenimiento del mismo.

Reestructurar las clases que se han vuelto muy grandes, muy confusas o que perdieron el propósito.

Delphi 2005+ incluye herramientas de refactoring que simplifican el proceso.

    De entrada por salida: Todo, en un solo paso.

Una vez estemos marchando, es tiempo de acelerar el paso. Para ello, debemos procurar hacer un “Build” de absolutamente todo, en UN SOLO PASO. Para ello, otra herramienta: Nant / Want o si tiene como, FinalBuilder.

Esto incluye:

  • Obtener la ultima versión ESTABLE del código, ponerlo en OTRA MAQUINA (o en su defecto, otro directorio). ESTABLE= La última versión que compila y pasa las pruebas de unidad correctamente y que se encuentre en el sistema de control de código fuente. La versión que tienes localmente en la cual trabajas NO SIRVE.
  • Compilar el proyecto, en base a lo anterior usando Want, Nant o FinalBuilder o en el peor de los casos, un archivo .BAT.
  • Ejecutar las pruebas que estén automatizadas, estas son las pruebas que no son de unidad, como los script que verifican las páginas Web, ejecutando Dunit.
  • Generar (si aplica) los scripts de base de datos que crean nuevos archivos y actualizan los viejos
  • Extraer todos los archivos que se necesita el instalador.
  • Generar el log de cambios (change log).
  • Generar las ayudas.
  • Generar el instalador. Para ello debe ser un sistema de generar instaladores que pueda invocarse por linea de comandos, como InnoSetup.
  • Copiar el instalador a un sitio de prueba. Notificar a quienes hacen las pruebas manuales

Y una vez terminado lo anterior:

  • Copiar el instalador a(los) medios de distribución, como CDs, montarlo al sitio Web para descarga, etc...

Si necesitas ayuda en ver como implementar estas ideas, el sitio de www.joelonsoftware.com tiene mucha información, parte de ella en español.

    Repasemos:

Ya que los archivos están organizados, es muy fácil montar una herramienta de código fuente, la cual nos permite identificar los cambios realizados, conocer en que archivos se solucionaron los errores e implementamos los requerimientos, que los tenemos en una lista de tareas y errores, los cuales proveen la dirección y enfoque a la hora de trabajar, usando técnicas de depuración/verificación automatizadas que permiten re-asegurar que cada parte del programa, tal como las partes de una silla, encaja perfectamente; y nos permite re-estructurar el código interno en formas mas efectivas sin temor a causar efectos colaterales desconocidos. Con lo anterior, podemos generar un entorno de “despliegue” eficiente, porque podemos obtener la ultima versión estable del código, compilarla, probarla y empaquetarla, para que al final, tengamos nuestro programa listo para la acción!

Listo, ahora tenemos un taller de programación. Ya pueden colgar en las paredes las fotos de las chicas ;)

Server Response from: ETNASC04