«La ley de Hofstadter: Siempre se tarda más de lo que uno espera, aunque se tenga en cuenta la ley de Hofstadter.»
DOUGLAS HOFSTADTER, especialista en ciencia cognitiva, filósofo, académico. Se obtiene una aplicación que implementa los requisitos que se planifican, solo falta desarrollar la consulta de tareas para completar como mínimo las funcionalidades llamadas básicas, es decir, tanto el CRUD de las tares como de las listas, así como su visualización y la búsqueda de tareas. Esto se considera como un producto mínimo del cual partir y probar durante un corto periodo de tiempo para en un hito posterior añadir funcionalidades de las indispensables y optimizar el núcleo creado.
El resultado es una interfaz simple de organización de tareas. Es necesario la implementación de más funcionalidades como el poder obtener fácilmente una vista de tareas de cualquier día, semana o mes a modo de un calendario en el cual seleccionar.
El desarrollo lleva más tiempo del esperado, más aún cuando no se tiene conocimiento del lenguaje de programación a utilizar. Al quedar poco tiempo para la entrega se decide dejar de buscar la optimización de cada elemento para poder continuar y no quedar estancado el flujo de desarrollo. Solo así se logra una continuidad y hasta homogeneidad en el número de puntos diarios que se cumplen en el desarrollo. Salvo algunos bloqueos respecto a desconocimiento de cómo implementar determinada
82
funcionalidad para la que no queda más que buscar la información hasta dar con una solución viable. Pero sin detenerse a buscar una solución más eficaz.
Se tiene cuidado de elaborar una interfaz que se adapte a diferentes tamaños de pantalla. El utilizar Bootstrap ayuda a ello, sin embargo, se debe mejorar.
A continuación se muestra la interfaz resultante. En Fig. 4.4.1 el tablero de trabajo principal con las tares y en Fig. 4.4.2 las listas en donde se puede acceder a las tareas que dispone cada lista.
Fig. 4.4.1: Aplicación - Vista principal
83
4.5.
Test
«Tenga cuidado con los errores en el código anterior; solo he demostrado que es correcto, no lo probé.» DONALD KNUTH, científico de la computación, profesor,
ganador del premio Turing. Los test son una parte importante del desarrollo software para controlar su correcto funcionamiento. Durante el desarrollo del código se realiza pruebas de tipo unitarias para comprobar el correcto funcionamiento de las funciones implementadas. Sin embargo, estas pruebas no son exhaustivas ni programadas sino una simple lista de comprobación de lo que se espera realice el programa. A esta lista de comprobación se añade elementos según se avanza en el desarrollo de funcionalidades, y se vuelve a comprobar al completo en cada iteración ya que es usual que al corregir un comportamiento indeseado de una función se termina provocando que algo que ya funciona como se desea cambie su comportamiento.
De igual forma para comprobar la integración en el sistema la comprobación que se realiza es mediante una lista sencilla de eventos a comprobar. No se implementa funciones que comprueben el correcto funcionamiento de las funciones que implementan la funcionalidad del sistema por ahorro de tiempo. Se es consciente de la necesidad de automatizar estas pruebas, pero se hace poco productivo cuando aún se realizan cambios.
4.6.
Documentación
«No documente código incorrecto. Reescríbalo.» BRIAN W. KERNIGHAN Y P. J. PLAUGER, en The Elements of Programming Style. La filosofía que se sigue es la de intentar crear funciones que implementen funcionalidades específicas de una forma modular y con independencia. El llevar a cabo ésta filosofía da un primer conflicto al inicio del desarrollo ya que es la primera vez que se utiliza un lenguaje de programación asíncrono. Esto provoca que no se pueda extraer código libremente para colocarlo en una función independiente puesto que no se ejecuta de una forma secuencial. Por lo tanto, se ve obligado a dejar el código de una forma anidada dentro de una función para poder lograr la secuencialidad deseada. Cierto es que se llega a leer sobre que el lenguaje implementa una serie de funcionalidades que permiten esta secuencialidad para evitar anidamientos innecesarios y una mayor claridad del código, pero no se llega al estudio completo de estas funcionalidades puesto que por ahora prima el desarrollo inmediato y no dedicar más tiempo en optimizar,
84
además que es prematuro buscar optimizar y causaría retrasos en la obtención de un primer producto mínimamente viable.
La lógica que se sigue es la de utilizar un nombrado que describa lo mejor posible a las funciones, variables, parámetros, etiquetas. Que sean auto-identificables. Se evita típicos nombrados de variables con una sola letra o cosas por el estilo, salvo índices de bucles que solo sirven como índices. De esta forma se busca que el código se auto-documente a sí mismo facilite una documentación posterior, previa reescritura y mejora del propio código.
5
87
EVALUACIÓN
5.
« Que esté correcto es claramente la primera calidad. Si un sistema no hace lo que se supone que debe hacer, entonces todo lo demás acerca de él importa poco.» BERTRAND MEYER, investigador, escritor, informático. En este apartado se documenta lo relacionado a la evaluación de usabilidad tanto del prototipo de baja fidelidad como de lo desarrollado. Esta evaluación se intercala con el desarrollo puesto que una vez se termina el diseño de baja fidelidad se realiza una primera evaluación, se pasa al desarrollo de la aplicación y se realiza una segunda evaluación pero con la aplicación.