En un trabajo realizado conjuntamente por investigadores de la Universidad Rey Juan Carlos y Delft University of Technology (Holanda), en el que también ha colaborado Programamos, se han anallizado más de 230.000 proyectos del repositorio de Scratch para estudiar la presencia de código repetido, producido al copiar y pegar código desde otros programas o proyectos.
Duplicar código es una mala práctica, ya que dificulta el mantenimiento y la modificación de los proyectos, que en Scratch puede evitarse mediante la definición de bloques propios y el uso de clones. De hecho, en un experimento con 61 estudiantes se demostró que aquellos programas que incluían código duplicado resultaban significativamente más complicados de modificar y arreglar.
¿Cómo de frecuente es el copia-y-pega en los proyectos del repositorio de Scratch?
De los 231.050 proyectos que fueron estudiados, 46.653 (20,19%) contienen al menos una sección de código duplicado. Por el contrario, tan solo 17.863 proyectos (7,73%) utilizan bloques definidos por el usuario, y 22.843 (9,88%) hacen uso de clones.
¿Los proyectos avanzados también presentan copia-y-pega?
Nuestra hipótesis era que los proyectos avanzados, creados por aprendices que ya tenían un buen nivel de programación, no incluirían código duplicado. Sin embargo, tal como puede verse en la siguiente imagen, muchos proyectos avanzados, incluso con 20 o 21 puntos de Dr. Scratch, también incurren esta mala práctica.
¿El uso de bloques propios o de clones elimina el copia-y-pega?
Nuestra hipótesis era que una vez los estudiantes han aprendido a utilizar bloques propios y clones dejarían de copiar y pegar código. No obstante, los resultados de la investigación muestran un panorama distinto, puesto que si bien el uso de estas funcionalidades retrasa la aparición de código duplicado, éste no se elimina completamente, lo que indica que incluso programadores que saben cómo evitar esta situación siguen incurriendo en ella, especialmente al programar proyectos muy avanzados.
Una de las razones que se discuten en el artículo para explicar esta situación es que Scratch no permite reutilizar bloques creados por el usuario en diferentes personajes, lo que obliga al programador a copiar esos bloques y pegarlos en otros personajes de sus proyectos.
Una de las conclusiones más interesantes de este trabajo es, desde nuestro punto de vista, que parece que el momento ideal para trabajar en el aula el código duplicado y las formas de evitarlo es cuando los aprendices estén programando proyectos de 10 puntos de maestría de Dr. Scratch. En ese momento, tal como indican los datos, los aprendices comienzan a tener la necesidad de implementar funcionalidades similares en varios sitios del proyecto, pero aún no saben cómo utilizar bloques propios y clones.
Y tú ,¿has detectado que tus estudiantes duplican código habitualmente? ¿Cuándo y cómo abordas esta situación en tus clases?
Puedes acceder gratuitamente a una copia del artículo original en el siguiente enlace:
Hola!
No me he mirado el artículo (aún!), pero yo creo que Scratch, está pensado para ir construyendo los programas «sobre la marcha», y para ir haciedo «tinkering», sin realizar grandes diseños algorítmico previos. Si en ese diseño previo muchas veces es difícil pensar en los bloques propios que necesitarás o en estrategias que usen clones, así que me parece bastante normal que, en general, haya muchas duplicaciones de código.
De hecho me parece que el equipo de Scratch fue bastante reticente a añadir los bloques propios (esperaron al 2.0), ya que nunca han querido que se convierta en un lenguaje de programación «profesional», sino más bien en un medio de expresión.
Seguramente cuando un alumno llega a plantearse estas cuestiones, ya está preparado para dar el salto a otros lenguajes, no os parece?
Saludos!
Hola, Edu,
Un comentario realmente interesante. Muchas gracias por compartir la reflexión.
Si bien lo que comentas es cierto, navegando por el repositorio de proyectos Scratch es fácil encontrarse con proyectos avanzados, complejos, que han necesitado de muchas horas de trabajo por parte de su creador. Y, sin embargo, son proyectos que es habitual que incurran en malas prácticas (como el código duplicado, o el uso de nombres por defecto en objetos, por ejemplo), que podrían evitarse con poco esfuerzo y que tendrían un impacto claro en el tiempo de desarrollo del proyecto, entre otras cuestiones.
¿Por qué estos programadores avanzados, que incluso han usado clones y bloques propios en su proyecto, siguen incurriendo en estas malas prácticas? Mi hipótesis es que probablemente nadie les ha explicado nunca los beneficios de no hacerlo. Por eso en Dr. Scratch mostramos mensajes con consejos a los programadores avanzados, de forma que conozcan estrategias que les ayuden a ser más eficientes y mejores programadores.
Saludos!