No copie y pegue el código. Escríbalo. ?

Escribir código puede ayudarlo a desarrollar una mentalidad de aprendizaje

¿Quieres descifrar algún código? Cámbielo muy rápido antes de siquiera comprender lo que hace.

Ahora está practicando la programación de Cargo Cult, un estilo de desarrollo de software en el que ignora cómo funciona un fragmento de código y su relación con el código que lo rodea.

El término programador de culto a la carga puede aplicarse cuando un programador de computadoras que no tiene experiencia con el problema en cuestión copia un código de un lugar a otro con poca o ninguna comprensión de cómo funciona o si es necesario en su nueva posición.

- Programación de Cargo Cult en Wikipedia

Cuando un desarrollador copia un fragmento de código que no comprende y lo usa con la esperanza de solucionar algún problema, está practicando la programación de Cargo Cult. Esto aumenta el riesgo de efectos secundarios no deseados.

Cuando un desarrollador lee un fragmento de código que no comprende y aún lo cambia con la esperanza de solucionar algún problema, también está practicando la programación de Cargo Cult.

El problema, en este caso, no es que el desarrollador esté copiando algo. Cualquiera puede copiar un fragmento de código, comprenderlo, aprender de él, usarlo y aún así tener un menor riesgo de efectos secundarios no deseados.

La programación de Cargo Cult, por otro lado, representa un malentendido fundamental de los pasos probados para aprender del código de otras personas.

Esta es la forma más eficaz de aprender en este contexto:

  1. Leer un fragmento de código.
  2. Comprenda todas las características del idioma que se utilizan allí.
  3. Comprenda todas las características de las bibliotecas / marcos que se utilizan allí.
  4. Aprenda los conceptos básicos de esas bibliotecas / marcos.
  5. Comprenda lo que hace cada línea y el propósito de esas bibliotecas / marcos en el contexto de ese fragmento de código.

Para alguien que comienza a trabajar con un nuevo idioma, esto será extremadamente difícil. La cantidad de información que un ser humano necesita retener para comprender de manera eficiente incluso un pequeño fragmento de código es tan grande que podría olvidarse de inmediato. Lo que podemos hacer es aprovechar ciertos aspectos de cómo el cerebro humano está acostumbrado a aprender cosas, consciente o inconscientemente, con algunas técnicas probadas.

Una de esas técnicas es la práctica bloqueada. Básicamente, es donde aprendes "realizando una sola habilidad una y otra vez, siendo la repetición la clave".

Sin embargo, esta no es la mejor manera de aprender. Está comprobado que, cuando aprende intercalando diferentes variaciones de la misma habilidad, aprenderá de manera más eficiente.

En ingeniería de software, podemos aprovechar las prácticas de aprendizaje bloqueadas e intercaladas cuando escribimos el código en diferentes contextos, en lugar de simplemente copiarlo y pegarlo .

Al copiar y pegar fragmentos, solo estamos leyendo (si es que nos molestamos en hacer eso). Y según la relación del Cono de experiencia, es posible que aprendamos solo una pequeña parte de la información que consumimos porque es demasiado abstracta.

Compare esto con aprender mejor escribiendo ese fragmento de código. Esta es una experiencia más directa y decidida. Obliga a su cerebro a comprender todos esos patrones diferentes y a aprender de manera más eficiente.

Escribir código en lugar de copiar y pegar proporciona un mejor retorno de la inversión en el aprendizaje porque estamos practicando en lugar de solo leer.

Nombrar cosas se considera uno de los aspectos más difíciles de la programación. Cuando copiamos código sin entenderlo, corremos el riesgo de romper algo al sobrescribir nombres de variables, nombres de funciones o clases.

Si, en cambio, entendemos el código primero, luego lo escribimos con nuestras propias palabras, podemos cambiar el nombre de las cosas de una manera que se adapte a nuestra aplicación y garantizar que no tengamos ninguna colisión de nombres, incluso si el resultado final es funcionalmente el mismo que el fragmento de código en el que nos basamos.

Además de eso, si copiamos el código de un lugar en nuestra base de código a otro, existe la posibilidad de que copiemos los tokens que no son necesarios u olvidemos cambiar los tokens que deberían haberse cambiado.

Tome el siguiente fragmento de HTML, por ejemplo:

Al duplicar ese código para crear una nueva entrada, es probable que olvidemos cambiar el atributo for del elemento de etiqueta , lo que romperá el comportamiento previsto para la nueva entrada.

Este ejemplo es interesante porque es el tipo de funcionalidad que es difícil de probar, incluso con regresión visual. Depende en gran medida de las pruebas estáticas, como una revisión de código, para asegurarse de que el código se escribió para el propósito previsto. (En este caso, para propagar eventos del mouse a la entrada para el mismo id de la etiqueta para el atributo).

Lo mismo ocurre con las pruebas. Cuando copiamos una prueba que ya está pasando en lugar de crear una nueva desde cero, corremos el riesgo de no cambiar los tokens necesarios que de otra manera causarían que la prueba falle.

En este caso, sin embargo, podemos evitar este error utilizando el desarrollo basado en pruebas, una mentalidad basada en crear primero una prueba fallida y luego cambiar el código de la aplicación para que pase. Esta mentalidad nos permite estar seguros de que es menos probable que nos perdamos de algo o creemos falsos positivos.

En lugar de copiar el código sin entenderlo, aprenda del código de otras personas y practique sobre él. Esto maximizará su ROI de aprendizaje.

Después de todo, el recurso más valioso de un desarrollador es el cerebro, no los dedos.

Gracias por leer. Si tiene algún comentario, comuníquese conmigo en Twitter, Facebook o Github.