by 
Latisha McNeel, Desarrolladora Full Stack en G2i
Este artículo apareció por primera vez en G2i .
La programación es parte arte y parte ciencia. ¿Cómo encaja la narración de historias con su código en esta dicotomía?
Una historia es un relato de un conjunto de eventos o personas, reales o imaginarias. El código es un sistema de palabras, letras o cifras que se sustituyen por otras palabras, letras o cifras, especialmente con fines de secreto o instrucciones de programación. A veces, al leer código (ciencias de la computación), se aplican ambas definiciones. En la charla sobre la inclusión, todos, todos los seres humanos, deberían poder utilizar las aplicaciones o productos que creamos. Si estamos construyendo para todos, ¿por qué entonces estamos escribiendo código como si solo quisiéramos que aquellos con nuestro anillo decodificador sean colaboradores? ¿O solo queremos que la computadora pueda decodificar lo que escribimos?
Ya sea que estemos escribiendo una novela, un cuento, un artículo o un código, nuestra audiencia son siempre nuestros semejantes. La computadora puede interpretar las declaraciones tanto si usamos la forma más concisa de escribir un algoritmo como si usamos la forma más legible. A veces nos preocuparemos por la optimización de una línea. Necesitaremos que la línea sea más rápida. Lo que siempre nos importa es si podemos entender o no lo que hace la línea cuando la leemos. Tener que adivinar lo que está haciendo una línea de código alimenta el síndrome del impostor con el que muchos de nosotros luchamos.
En su mayor parte, construimos nuestras aplicaciones con lenguajes de programación de alto nivel. Lenguajes de programación que están pensados para que los humanos puedan entenderlos y deben ser compilados o interpretados para que los comprendan las computadoras. Si escribimos en un idioma que se traducirá para la computadora, ¿por qué seguimos escribiendo código que también requiere tanta traducción para los humanos?
¿Qué es contar una historia con tu código?
Algunas personas piensan que la programación es ciencia y matemáticas con reglas y fórmulas. Otros piensan que programar es un arte. La computadora verá el código en blanco y negro, correcto o incorrecto, encendido o apagado: dos opciones. Los humanos leerán el código y lo leerán subjetivamente, de la misma manera que leen un artículo de noticias o Shakespeare. El arte es subjetivo y, como somos críticos, tendemos a estereotipar el arte como sin reglas, mientras que con la ciencia queremos ser metódicos, seguir una fórmula, demostrar algo «correcto». Incluso entonces, la ciencia y el arte no están tan alejados. La arquitectura usa tanto las matemáticas como la ciencia y, sin embargo, llamamos hermosos a los edificios. Intentamos encontrar nuevas formas de combinar las reglas en estructuras más hermosas. El arte usa la ciencia cuando combina dos colores para crear un nuevo color y tiene reglas de composición. La programación también es ciencia y arte, y escribir código sigue siendo una forma de escribir.
¿Por dónde empiezo a contar la historia?
La historia comienza con la arquitectura y la estructura de carpetas. El tío Bob dice que «las buenas arquitecturas gritan su uso previsto». Una parte de la arquitectura es la estructura de carpetas y el nombre de la estructura de carpetas. Al nombrar cosas, el tío Bob afirma que «elegir nombres en la programación es tan importante como nombrar a sus hijos».
Sobre eso, un programador necesita conocer el negocio y tener una buena comunicación con las partes interesadas. El grupo debe decidir sobre una taxonomía. Si el nombre de las cosas se basa en la terminología del negocio, entonces el programador puede hablar con las partes interesadas y discutir el código con más claridad. Recuerde, cambiar los nombres de las cosas en el código suele ser una operación barata. Un buen editor de codificación hace la mayor parte del trabajo por usted. No es necesario saber todo sobre el negocio desde el primer día.
Al nombrar los sustantivos y verbos de programación, comenzamos con la taxonomía del dominio o negocio. Podemos usar un diccionario de sinónimos para encontrar una palabra mejor para una palabra que no parece lo suficientemente específica. Podemos cuestionar el uso de la misma palabra de diferentes maneras. Esto lleva a una comparación de los principios DRY al escribir una novela y al escribir un código.
Al escribir una novela, uso un diccionario de sinónimos para variar mi elección de palabras y ver si puedo encontrar una palabra más descriptiva cuando me doy cuenta de que usé la palabra «caminar» 20 veces y tal vez «pasear» o «correr» fue una mejor opción . En programación, DRY significa que no quiero escribir el mismo bloque de código varias veces; no quiero tener que mantener un código que haga lo mismo más de una vez. En programación, quiero absolutamente usar la misma palabra para describir lo mismo cada vez. Quiero coherencia con la elección de palabras.
¿Cuál es un ejemplo de contar una historia con código?
Mira los siguientes dos ejemplos de código:
Son solo un par de declaraciones de objetos: un personaje, en un juego, en una historia, no lo sabemos. Pero hay algunas diferencias. ¿Es el personaje general mejor que myCharacter? Creo que sí. En última instancia, puede que este no sea mi personaje, podría ser solo un personaje en un juego que construyo con otros desarrolladores. El prefijo my es extra – Grammarly me dice que uso palabras extra cuando escribo todo el tiempo.
La otra diferencia es una declaración de propiedad: una es Mover y la otra es simplemente Mover. ¿La palabra adicional hace una diferencia en la legibilidad, en la historia aquí? El primero me dice que el personaje llamado Latisha se está moviendo. No sabemos mucho más, pero sabemos que Latisha se está moviendo. El segundo solo dice move: cierto. Eso lleva a más preguntas. ¿Latisha se está moviendo, tiene la capacidad de moverse? ¿Mover es un verbo o un sustantivo en la propiedad? No lo sabemos, podemos hacer suposiciones, pero la línea está abierta a la interpretación.
No sabemos si el personaje tiene la capacidad de moverse, como caminar, volar o correr, O si el personaje, en realidad, debería ser un usuario y se está mudando de casa o apartamento. ¿Cuántas historias se pueden inventar con solo las muestras anteriores? ¿Cómo podríamos cambiar los detalles para permitir que el próximo desarrollador o lector tenga más contexto en la historia que estamos contando?
Una muestra de código más: hace referencia a los objetos anteriores:
¿Cómo se leen las declaraciones anteriores?
Uno pregunta claramente si el personaje se mueve. Todavía no sabemos si el personaje camina o se muda de casa.
El otro, pregunta si mi personaje se mueve. Es una pregunta mucho más ambigua.
¿Cómo mejoro mi capacidad para contar una historia?
Un rasgo importante: el cuidado .
Debe preocuparse por su código y debe preocuparse por la audiencia que leerá su código.
Tres elementos para ganar experiencia:
- Leyendo
- Escritura
- Revisión / Refactorización
El tío Bob afirma que la relación entre la lectura de código y la escritura de código es 10: 1. Stephen King afirma que «cuanto más lee, menos apto es para hacer el ridículo con su lápiz o procesador de textos». Cuando lea código, sea crítico. Note lo bueno y lo malo. Observe su primera reacción a lo que está leyendo. Preste atención a la historia que está construyendo en su cabeza mientras lee el código.
Puede leer el código todo el día, todos los días. Si nunca comienza a escribir ninguno y a debatir sobre la elección de palabras, nunca obtendrá experiencia escribiendo código. No importa por dónde empieces y no es necesario que sea perfecto la primera vez. Empiece con lo que sabe. Kent Beck dice: «Haz que funcione; luego hazlo bien; luego hazlo rápido ». En eso, céntrese en la legibilidad y la claridad de la historia que está construyendo.
Revisión y refactorización. Necesita revisar su propio código, necesita refactorizar su propio código y necesita que otras personas revisen y refactoricen su código. Si estuviera escribiendo un trabajo para una clase o un artículo o una novela, alguien lo revisaría o lo editaría. Puede dejarlo por un tiempo, por un mes, por 3 meses. Cuanto más tiempo pase, menos sesgo tendrá cuando lo vuelva a leer. Parecerá una nueva historia y tendrás más experiencia en codificación.
Mi lista de lectura recomendada
Programación
Código limpio Robert C. Martin (tío Bob)
El diseño de las cosas cotidianas Donald A Norman
Escritura
En la escuela secundaria, se recomendaron dos libros más para escribir; todavía estoy tratando de terminarlos.
Un cuarto de la propia Virginia Woolf
Un retrato de un joven como artista James Joyce
