Una de las primeras cosas que buscaría en cualquier entorno de desarrollo serían las opciones disponibles en cuanto a depuración, perfilado y control de calidad del código propiamente dicho. Por ello me gustaría detenerme en esta ocasión en ver cada una de las opciones que nos ofrece Xojo en este sentido.
Para ello hemos de tener en cuenta que la licencia capaz de proporcionar las máximas prestaciones es la Pro, puesto que en ella no sólo se incluye la capacidad de realizar depuración local, sobre la misma plataforma en la que estemos desarrollando, sino llevar a cabo también depuración en remoto y que nos permite, por ejemplo, correr la aplicación sobre OS X mientras que el IDE y el propio depurador están ejecutándose en nuestro equipo Windows (o viceversa).
Sobre la capacidad básica de depuración, en Xojo también contamos con un perfilador de código, lo que se traduce en una excelente herramienta mediante la cual podremos observar donde se producen los "cuellos de botella" o cuales son los puntos críticos más susceptibles de concentrar nuestros esfuerzos de optimización (recuerda: ¡evita la optimización prematura en tus aplicaciones!).
Y sobre el perfilador de código, también se nos puede escapar otra característica que por su nombre podría parecer relacionada, sin estarlo. Se trata del Analizador de Proyecto y de su hermana pequeña Analizador de "x" donde hemos de sustituir la incógnita por el elemento del proyecto (generalmente una clase, módulo o interfaz de clase) que tengamos seleccionado en ese momento.
Personalmente soy un gran aficionado de cualquiera de estas dos opciones, puesto que sus funciones no son otras que la de ayudarnos a mantener un código limpio, avisándonos para ello de qué variables descansan para siempre en el campo de los bits compilados sin llegar a ser usadas, llevándolo también al terreno de los parámetros de método y de eventos (¿carne de refactorización?).
En cualquier caso, algo tan simple como la invocación de cualquiera de estos dos comandos significa que, en unos días, semanas o meses no te encuentres rascándote la cabeza para intentar averiguar el por qué de la declaración de variables y otros componentes que nunca llegan a utilizarse y nunca debieron de estar por tanto ahí.
Por último, algo fundamental y poco menos que imprescindible en cualquier lenguaje que se precie, encontramos las pruebas unitarias, y que nos permitirán asegurarnos de que los métodos de nuestras clases se comportan tal y como deben arrojando los resultados esperados, independientemente de las iteraciones que realicemos y de los cambios que apliquemos a lo largo de las diferentes versiones de nuestro proyecto.
En este aspecto, he de reconocer que el framework utilizado por Xojo para este fin no es todo lo suave que podría desear, más aun en comparación a cómo queda resuelto por otros lenguajes de programación.
No es tanto en el procedimiento en sí, sino en el hecho de que la presentación de los resultados no está integrada con el IDE sino que se presentan en una ventana (elemento de interfaz de proyecto) que, por tanto, ha de estar ahí. Por otra parte, y tal y como ocurre también en una gran cantidad de frameworks dedicados a esta misma función, las pruebas unitarias de Xojo no quieren saber absolutamente nada sobre e correcto funcionamiento de tu interfaz de usuario… eso corre de tu cuenta.
Depurando aplicaciones Xojo
Una vez vista la pequeña introducción sobre qué herramientas encontrarmos en Xojo para mantener el control y la calidad de nuestros proyectos (todas ellas disponibles bajo el menú Project, por cierto), comenzaremos viendo los principales detalles de cada una de ellas.
El depurador es fundamental en cualquier lenguaje, y en Xojo encontrarás la capacidad de definir los típicos puntos de parada sobre cualquiera de las líneas de código antes de que ejecutes la aplicación y también durante la aplicación (incluyendo en este sentido también la capacidad de eliminar puntos de parada previamente definidos).
Una vez se alcanza un punto de parada durante la ejecución del código, el panel de depuración permite cambiar entre las diferentes llamadas contenidas en la Pila, presentando en cada caso el conjunto de variables locales y globales para el examen de sus contenidos. Todo ello por cada uno de los hilos que se estén ejecutando simultáneamente en nuestro programa; una verdadera ventaja para cazar muchos de los bugs en aplicaciones multi-hilo.
En este sentido destaca la capacidad de ver la información textual en cualquiera de las codificaciones soportadas o bien en binario (editor hexadecimal), así como la representación gráfica de las variables que contienen imágenes o información de color (entre otras); e incluso en algunas propiedades de objeto se nos presentará la opción de modificar la información en tiempo de ejecución.
Lo que no podemos hacer por el momento es establecer puntos de parada condicionales. Es decir, aquellos que nos lleven al depurador cuando una variable o propiedad alcance un valor determinado; y que en muchos casos resultarían de una utilidad tremenda.
Otra cosa que no podremos hacer es modificar el código sobre la marcha mientras que se está llevando a cabo la sesión de depuración; algo inherente al propio lenguaje y capacidades de compilación estática (declaración de tipos y demás), pero que en muchos casos nos obliga a detener el proceso, realizar correcciones mínimas y volver a ejecutarlo de nuevo. (¡Atento, porque si bien en la sesión de depuración encontrarás un botón de Edición que, efectivamente, permite editar código, dichas ediciones no tendrán efecto inmediato sino que la sesión continuará realizándose sin tener en cuenta los cambios!)
Sobre las posibilidades de exploración, como todo buen depurador es posible llevar acciones paso a paso, no entrar en la ejecución de un método o función o bien salir precisamente del método que se esté ejecutando en ese momento.
Depuración Remota
Algo que en principio podría parecer complejo no lo es en absoluto. De hecho sólo tendremos que instalar el complemento encargado de establecer la comunicación con nuestro equipo (denominado Remote Debugger y que está disponible en la carpeta Extras de la distribución, tanto para aplicaciones de escritorio como para aplicaciones de Consola y para sistemas operativos Windows, Linux y OS X).
A partir de ahí, en los ajustes de configuración del IDE sólo quedará añadir cualquier equipo remoto hacia el que deseemos enviar nuestra aplicación, y para ello podremos introducir manualmente la dirección IP o bien utilizar la capacidad de "descubrir equipos automáticamente en la red", para lo cual Xojo probablemente utilice sus propias clases (Trivia: el IDE de Xojo está creado con… Xojo. Es decir, que "comen su propia comida").
Cuando el equipo llega al equipo remoto este se ejecuta y nosotros recibiremos igualmente los puntos de parada con la misma información que si el programa se estuviese depurando en local, con la ventaja añadida de que efectivamente estará corriendo sobre la misma plataforma que se hiciese un despliegue real. (Por cierto, con la configuración adecuada de nuestra red, nada nos impide depurar una aplicación en remoto que se esté ejecutando a cientos o miles de kilómetros de distancia.)
Ejecutar y ejecutar pausado
Es probable que muy pocos desarrolladores deparen inicialmente en que existe una opción Run (la utilizada por omisión para Ejecutar la aplicación con o sin puntos de parada), y otra con el texto Run Paused. ¿Cuál es la funcionalidad de esta última?
La característica "Ejecución Pausada" está pensada para aquellas configuraciones de nuestros ejecutables en las que es preciso añadir "algo más" para que el entorno de ejecución sea realmente el esperado, como por ejemplo aplicaciones o recursos auxiliares dependientes de la aplicación principal, y que no pueden resolverse simplemente mediante una de mis características favoritas: los pasos de compilación que permiten añadir acciones como pasos de pre o post-compilación, o copiar los recursos indicados sobre una ubicación determinada.
Así, cuando hacemos una ejecución pausada el IDE de Xojo nos presentará la aplicación ya compilada en la ubicación seleccionada como destino, con la diferencia de que permanecerá pendiente de reanudar la ejecución al momento en el que nosotros le indiquemos y, por supuesto, conservando todos los puntos de parada que hubiésemos indicado.
Pefilador de código
Esta característica es una de la que deberías de ejecutar en todos tus proyectos de Xojo, si no antes de desplegar la versión final, sí en las revisiones menores de cada una de tus aplicaciones.
Su finalidad no es otra que mostrarnos la cantidad de veces que se ha invocado cada uno de los métodos involucrados en un flujo concreto de la aplicación (lo siento, no hay un modo sencillo de automatizar esto) y, por tanto, la cantidad de tiempo consumido por cada uno de ellos. De este modo, podremos identificar cuáles son las áreas de la aplicación que requieren de un mayor énfasis por nuestra parte a la hora de optimizar el código o los algoritmos utilizados.
El IDE de Xojo guardará junto con el proyecto todos los informes de perfilado correspondientes a la misma sesión, de modo que podremos ver la evolución a lo largo del tiempo. Por desgracia, no se conservan una vez que cerremos y volvamos a abrir el proyecto. Si deseamos conservar el histórico por cualquier motivo, corre de nuestra cuenta.
Analizador
En cuanto al analizador de proyecto y de clases, son dos características que deberíamos de utilizar con cierta frecuencia y en ambos casos nos permitirá ver por tipo o por ubicación tanto los errores detectados como las advertencias sobre componentes que en el fondo no aportan utilidad real en la ejecución de la clase, módulo o aplicación.
Arreglar cada uno de los problemas detectados es una operación tan simple como seleccionar las diferentes entradas del listado, acción que nos llevará al Editor de Código situándonos justo en el punto sobre el que hemos de aplicar la corrección indicada.
Por supuesto, algunas de las advertencias son un exceso de celo por parte del precompilador y, salvo que queramos meternos de lleno en refactorizaciones de clase o en aplicar alguna sobrecarga de métodos… lo mejor es dejarlo correr sin más; después de todo, este tipo de avisos no indican problemas reales del código y tampoco presentan un impacto en el rendimiento durante la ejecución del mismo.
Pruebas Unitarias
El framework utilizado por Xojo para realizar nuestras pruebas unitarias es el denominado por la compañía como XojoUnit, y de hecho no hay mejor forma de verlo en acción que ejecutando el ejemplo incluido en la carpeta con el mismo nombre como parte de la distribución. De hecho, si queremos añadir pruebas unitarias en nuestros proyectos el primer paso no será otro sino copiar la carpeta XojoUnit del framework desde uno de los proyectos de ejemplo (escritorio, web o consola) hacia el navegador de nuestro proyecto.
A partir de ese punto, tendremos que crear una subclase que será la contenedora de las pruebas unitarias, y también una subclase del controlador responsable de inicializar y coordinar las pruebas unitarias y la presentación de los resultados en la ventana utilizada por el framework.
Por último, será dentro de la subclase de pruebas donde hemos de añadir cada uno de los métodos responsables de realizar las comprobaciones deseadas. Los tipos de aserciones disponibles en el framework cubren el espectro típico: AreEqual, AreDifferent, AreSame, Fail, IsFalse, IsNil, IsNotNil, IsTrue, Message (muestra un mensaje en el área de mensaje para la prueba en cuestión), y Pass.
Código eficaz
Vistas las opciones disponibles para procurar que nuestro código esté libre de errores (dejando de un lado las ayudas del propio lenguaje, mediante la gestión de excepciones o bloques Try…Catch, por ejemplo), y también dirigidas a mejorar en lo posible su rendimiento y legibilidad, la próxima entrega la dedicaremos a uno de los puntos fuertes de Xojo: la gestión de bases de datos.
Hasta entonces, algunos enlaces de interés.
Sitio web de Xojo: www.xojo.com Blog de la compañía: blog.xojo.com Foros de Xojo: forum.xojo.com
Ver todos los comentarios en https://www.genbeta.com
VER 0 Comentario