Cómo resolver los ejercicios en Mumuki -y cometer la menor cantidad de errores posible.

Bueno, el título es medio engañoso. Siempre decimos que los errores son una parte fundamental del aprendizaje, y lo sostenemos. Sin embargo, pensamos en algunos consejos para que le saques el mayor jugo posible a la plataforma sin exprimirte tanto la cabeza.

Paso 1: leer bien la consigna.

¿Sabés a qué se debe la gran mayoría de los errores que se cometen en Mumuki? No se debe a la falta de habilidades tecnológicas. Tampoco es por errores en la lógica del código. ¿Sintaxis? Podría ser, pero no.

La mayoría de los errores en Mumuki suceden por falta de lectura del texto explicativo y de la consigna. Muchas veces saltamos directo al editor de código, intentando “suponer” lo que Mumuki nos pide que hagamos, o replicar la imagen que vemos en la consigna. Jugamos a ver si adivinamos lo que teníamos que hacer, antes de jugar a resolver el desafío que se nos propuso.

El texto que acompaña a cada ejercicio nos presenta un problema que debemos intentar solucionar, pero también nos explica conceptos teóricos y nos guía en la mejor forma de resolver ese problema. Además, si prestamos atención, nos especifica qué es lo que espera de nosotros.

Veamos un ejemplo. En el ejercicio “Enseñándole tareas a la computadora”, la consigna nos dice lo siguiente:

Si leemos con atención, vemos que tenemos que hacer dos cosas: por un lado escribir el procedimiento Poner3Verdes y, además, hacer un programa que utilice dicho procedimiento. Tenemos que aprender a detectar esas palabras claves.

¿Quién dijo que en Mumuki sólo enseñamos código? ¡A ejercitar nuestra lecto-comprensión!

Paso 2: leer bien la pista.

En el margen, medio escondida, a veces aparece la pista. No está en todos los ejercicios pero, si la ves, abrila.

La pista suele sugerirnos de qué manera solucionar el problema. A veces nos recomienda herramientas para que utilicemos. Otras, nos da consejos que debemos tener en cuenta para que nuestra solución no falle. En cualquier caso, es de gran ayuda para terminar de entender qué espera Mumuki que hagamos.

Paso 3: revisar la sintaxis.

Bien. Ya leíste y entendiste la consigna, tomaste en cuenta el consejo de la pista y, aún así, no funciona. Relees tu solución varias veces y tenés seguridad de que es correcta. ¿Qué puede estar pasando?

A diferencia de cuando nos comunicamos con otras personas, para que la compu nos entienda tenemos que escribir exactamente de la manera que ella puede entendernos. Y cuando decimos exactamente, nos referimos a que cualquier mínima diferencia puede hacer que nuestro código sea totalmente incomprensible para la máquina.

Un paréntesis de más, un punto y coma de menos, una mayúscula que debió ser una minúscula. A simple vista, cualquier humano puede entender lo que quisimos decir, pero no la computadora.

A eso lo llamamos un error de sintaxis. Es decir, cuando el error no está en el planteo conceptual de la solución sino en la forma en la que está escrito el código. Por eso, cuando “codeamos” es muy importante revisar lo que escribimos, caracter por caracter.

Prestá principal atención a las minúsculas, mayúsculas, paréntesis, llaves, y la redacción de las palabras reservadas de cada lenguaje. Por ejemplo, no es lo mismo escribir lenght que length.

Paso 4: leer el error.

Siempre que nos equivocamos, Mumuki nos da un feedback sobre nuestro error. Es decir, nos da una “devolución” sobre lo que tenemos mal o lo que podríamos mejorar. Es importante prestarle atención a lo que nos dice.

Veamos un ejemplo. Imaginemos que en Gobstones queremos repetir 4 veces los comandos Poner(Rojo) y Mover(Este) y, para lograrlo, escribimos el siguiente código.

Mumuki nos va a devolver la siguiente explicación sobre el error que estamos cometiendo:

¿Qué significa ese mensaje? Que se esperaba una llave, pero no se encontró. Es decir, nos está faltando abrir una llave. En el lugar donde debía estar esa llave se encontró un identificador con mayúsculas. Si revisamos el código que mandamos, podemos ver que la llave faltante debía ir luego del repeat(4), para encapsular los comandos que queremos que se repitan.

Paso 5: dividir en subtareas.

El mejor puntapié para resolver un problema es intentar identificar si puede dividirse en problemas más pequeños.

Miremos el siguiente tablero, imaginando que se trata de un molino de 4 aspas:

Hay distintas formas de lograr reproducirlo. Podemos escribir comandos para dibujar el molino bolita por bolita, sí. Pero podemos hacer algo mejor: evitar repetir código. ¿Cómo? Acá es clave pensar qué parte se repite y definir la estrategia a partir de eso.

En lugar de agarrar el problema grande, e intentar dibujar el molino completo, podemos pensar en dividir ese molino en partes más pequeñas. Vemos que hay algo que se repite: las aspas. Podemos escribir un procedimiento que sea DibujarAspa, y repetirlo 4 veces.

Reutilizar el código es una práctica fundamental en la programación. Por un lado, evita que escribamos innecesariamente los mismos comandos. Por otro lado, al organizarlo, hace que nuestro código sea más fácil de leer y de entender a simple vista.

Paso 6: elegir buenos nombres.

El imaginario colectivo suele representar a los programadores como hombres solitarios, que trabajan de noche encerrados con su computadora. Esa falacia es peligrosa. En primer lugar, cualquier persona puede programar, sin importar su género. En segundo lugar, el hecho de que una persona pueda programar sola, no significa que la actividad pueda prescindir del contacto con otros humanos. ¡Todo lo contrario!

Cuando escribimos un código, no es suficiente que lo entienda la computadora. Es necesario escribirlo de manera tal que lo pueda entender cualquier otra persona. Incluso que podamos entenderlo nosotros mismos, luego de pasado un tiempo de haberlo escrito.

A la computadora no le importa cómo se llamen los procedimientos que escribimos, siempre que los usemos, la compu va a saber que tiene que repetir los comandos que lo componen. Pero, para una persona, los nombres que les ponemos a las cosas las vuelven reconocibles y hacen que el código sea más fácil de entender.

Veamos la siguiente función:

A simple vista es difícil saber lo que hace. ¿Y si le ponemos otros nombres a sus elementos?

Las dos funciones devuelven los mismo, pero una nos “explica” mejor lo que hace. Es por eso que decimos que la función esPar es más expresiva que la funcion1.

Elegir buenos nombres para los elementos de nuestro código (variables, funciones, procedimientos, etc) es fundamental para que tanto nosotros mismos como otras personas puedan entender más fácilmente qué es lo que ese código hace.

Paso 7: esperar.

A veces, lo mejor que podemos hacer para mejorar nuestro código es abandonarlo -por un rato. Cuando estamos demasiado inmersos en un problema, la mente se nos nubla y es difícil que podamos pensar claramente. En esos casos lo más recomendable es simplemente dejar de programar por un rato. Salir a caminar, pegarnos una ducha, y descansar la cabeza. Muchas veces la solución a un problema se nos aparece mientras pensamos…en otra cosa.

No te lo vamos a negar. Aprender a programar puede ser un camino tedioso y no pocas veces frustrante. Pero te prometemos que también es un camino sumamente gratificante.

Si todavía no empezaste, ¿qué estás esperando? Hacé click acá y empezá a programar.