Modelo de enseñanza clásico
El modelo de enseñanza clásico con el cual se introducen los principiantes al mundo del desarrollo de software se puede resumir en los siguientes pasos:
- Arquitectura del computador (opcional, depende del nivel académico y conocimientos previos de los estudiantes)
- Algoritmia
- Pseudo código
- Modelado: UML o Diagramas de Flujo
- Pruebas de escritorio
- Introducción a la programación
- Estructura de un programa
- Editores de desarrollo integrados
- Estructuras de control básicas de algún lenguaje de programación
Los pasos anteriores son el modelo de enseñanza “ideal”, dado que antes de ver algún lenguaje (herramienta) el estudiante aprende elementos básicos y necesarios además de ganar un entendimiento más claro sobre el contexto en el que se ejecutan las aplicaciones.
En la actualidad, dado el acceso libre a mucha información, se forman muchos “desarrolladores empíricos”, o son introducidos al campo del desarrollo de software mediante la enseñanza de un lenguaje de programación como primer elemento. Es como si un ingeniero quisiera aprender a utilizar un software avanzado para el diseño de estructuras sin antes conocer de aritmetica, fisica y otras ciencias básicas que debe dominar para poder dar un buen uso a la herramienta. Este salto de pasos crea brechas de conocimiento las cuales impactaran a la persona en su carrera en el futuro.
Afortunadamente en algunas universidades e institutos de formación técnica, se hace mucho hincapié en el desarrollo de la lógica, habilidades matemáticas, algoritmia y arquitectura del computador antes de introducir el primer lenguaje de programación a los estudiantes.
Los centros de formación de programadores que inician con la enseñanza de lenguajes generalmente se orientan más al ámbito económico que a la calidad de sus programas. Pero este tema será material de otra entrada. Por ahora enfoquémonos en el programa “ideal” de enseñanza y cómo podemos mejorarla aún más.
Introducción del Test First Development (TFD)
Primer nivel: manual
El TFD es la práctica de diseñar PRIMERO las pruebas o validaciones de un programa antes de intentar implementarlo. Es una práctica estrechamente relacionada al Desarrollo Guiado por Pruebas o TDD (del inglés Test Driven Development), pero más básica y para la cual no se requieren herramientas específicas (librerías, frameworks, etc.).
En esencia en TFD, se le pide al desarrollador que cree, antes que el código, los casos de prueba con los cuales se evaluará el programa cuando esté codificado. Una forma simplista de verlo es como hacer una prueba de escritorio “ideal”, donde los valores de las variables controladas siempre son los esperados. Esta es la visión de caja-blanca o algorítmica, la cual asume un conocimiento de la futura implementación del software.
Otra forma de expresar los casos de prueba es desde el punto de vista del usuario final. En este caso nos enfocamos en las interacciones con la interfaz de usuario ya que estamos definiendo lo que el usuario percibirá antes de crear el programa.
Esta forma de TFD, la cual denominaremos la forma manual, debe ser introducida lo antes posible en la enseñanza del desarrollo de software. De hecho si se analiza bien, no es necesario que una persona sepa cómo utilizar un lenguaje de programación para poder definir casos de prueba. Desde que el estudiante aprende a crear algoritmos sencillos en pseudocódigo o lenguajes de modelado visual como UML o Diagrama de Flujo, ya es posible crear un script de prueba que valide la funcionalidad descrita.
Segundo nivel: automatico (pruebas unitarias)
Luego de que el estudiante puede crear casos de prueba manuales (Scripts de prueba) y programas sencillos utilizando algún lenguaje de programación, se le puede introducir algún framework para crear pruebas unitarias automáticas.
Es cierto que un framework de pruebas unitarias utiliza técnicas de programación muy sofisticadas para un principiante, como meta-programación (reflection), proxies, mocks, anotaciones (decoradores), etc. Por tanto, es poco práctico exigirle a un principiante la habilidad de crear (programar) pruebas automáticas desde etapas tempranas del aprendizaje. Sin embargo, es posible entregarles cascarones de proyectos los cuales ya tengan las pruebas codificadas y estos simplemente vayan codificando sus soluciones y viendo como los casos de prueba van pasando de manera incremental. Para esto solo se les debe enseñar cómo correr las pruebas unitarias, lo cual es tan simple como correr un comando (mismo nivel de complejidad que lanzar el proceso del compilador por la consola), o presionar un botón en un entorno de desarrollo integrado.
Ventajas
Las ventajas de este los cambios propuestos en el modelo de enseñanza son muchas. Aquí solo resaltaremos las más importantes según nuestro criterio:
Código minimo necesario
Cuando se especificamos claramente los criterios de validación de un programa, naturalmente se tiende a escribir las sentencias mínimas necesarias para cumplir con esos casos de prueba. Cualquier sentencia o módulo adicional sería considerado un gasto o un esfuerzo innecesario
Sensación de avance y logro
Los casos de prueba inconclusos sirven como un camino trazado el cual consta de estaciones que debemos recorrer. Hasta tanto no hayamos pasado por todas estas no habremos terminado. Esto no da un punto focal y una visión clara del objetivo perseguido. Además conseguimos una solución gradual y una sensación constante de que estamos siempre más cerca de la meta.
Pensar como el usuario final
Uno de los interesados más importantes en todo proyecto de software es el usuario final de los sistemas construidos. La opinión de los usuarios puede impulsar un proyecto hacia el éxito o sumirlo en el fracaso. Al practicar TFD estamos constantemente poniéndonos, mentalmente, en los zapatos del usuario y pensando que tanto ayudará el sistema que vamos a construir a que este logre sus propios objetivos. También, al ejecutar los casos de prueba, validamos esos supuestos y experimentamos de primera mano el grado de satisfacción de los requisitos alcanzado con el sistema construido.
