Presentación

Cuando hace ejercicios de programación, trabajos prácticos o tutoriales, el trabajo que se tiene que desempeñar permanece relativamente guiado. Por ejemplo, cuando el profesor le pide que codifique una función, describe sus parámetros y el resultado esperado. Es usted el que tiene que establecer la lógica y realizar los tratamientos correctamente.

Por otro lado, al codificar un proyecto personal o un proyecto escolar, cuanto más avanza el proyecto, más problemas se encuentran: aparecen extraños errores y lo que es peor, con intermitencias: añadir funcionalidades se vuelve difícil y releer el código, complicado.

¿Por qué una persona capaz de configurar 20 funciones de 10 líneas se encuentra en dificultades en un proyecto de 200 líneas? A priori, estos dos desafíos parecen similares.

Sin embargo, no es el caso. De hecho, hay una diferencia crucial entre saber hacer ejercicios cortos y llevar a cabo un proyecto largo: se trata de la capacidad de diseñar un programa, organizarlo y estructurarlo. Esta habilidad no siempre se aprende en clase, generalmente por falta de tiempo.

Así, en este capítulo, para permitirle llevar a cabo proyectos largos, le transmitiremos los principios fundamentales del diseño de un programa.

Principios de concepción

1. Los tres grandes principios: Identificar/Estructurar/Mejorar

Para diseñar un proyecto informático largo, cualquier programador debe respetar los siguientes tres principios:

Identificar la información y las acciones/tratamientos.
Estructurar la información y las acciones/tratamientos.
Mejorar las elecciones de diseño.

Estos tres grandes principios no giran en torno a las técnicas de escritura de código. De hecho, llevar a cabo un proyecto de varias horas requiere otras habilidades, además de la programación.

Los programadores talentosos encuentran dificultades porque tienden a codificar rápido, sin tomarse el tiempo para pensar en el diseño, lo que produce código desorganizado. Al darse cuenta de que su diseño es básico, estos programadores reformularán las diferentes partes de su programa con la esperanza de mejorar su diseño. Desafortunadamente, sin reflexionar un poco sobre la estructura del programa, convierten su diseño tambaleante en otro diseño tambaleante e igualmente insatisfactorio.

El secreto para diseñar un programa largo es pararse y reflexionar. Ahora debe reflexionar considerando las necesidades y objetivos solicitados. Tomar este tiempo de reflexión significa alejarse de la escritura de código momentáneamente, y lo es tarea fácil para todos.

Los tres principios propuestos le ayudarán a lograr el diseño más adecuado posible; los detallamos a continuación:

Identificar la información y las acciones/tratamientos es el primer principio. Lo ideal es que se haga antes de escribir el programa. De hecho, cuando se le describe un proyecto, como PacMan, por ejemplo, sabe que será necesario representar en la memoria el entorno, así como los PacGums. También tendrá que gestionar los elementos del juego, como PacMan, los cuatro fantasmas, los bonus y los súper-PacGums. Obviamente, también será necesario gestionar las interacciones entre todos estos elementos: PacMan no debe cruzar las paredes; cuando pasa por un PacGum, este debe desaparecer, como los bonus en otros lugares. Los fantasmas pueden comerse a PacMan...

Variables

1. Identificar variables

a. Regla: 1 noción = 1 variable

Cuando enumera la información necesaria para realizar un tratamiento, está haciendo una lista, sin darse cuenta, de las variables que necesita. Por lo tanto, debe respetar la siguiente regla:

Cada noción debe estar representada por una variable

Pongamos un ejemplo. Si necesita crear un clon del juego PacMan, tendrá que mostrar los diferentes elementos del juego en la pantalla. Para ello, necesita conocer la posición de PacMan, los cuatro fantasmas y los bonus. Así, para tener esta información disponible, es necesario crear variables que almacenen las posiciones de elementos del juego, como xPacMan e yPacMan...

Cuando decimos que cada noción debe estar representada por una variable, ¡implica que no debemos elegir cero o varias!

En el primer caso, la ausencia de variables se produce cuando un programador escribe un cálculo dentro de otro proceso, como en el siguiente ejemplo:

if 0 < x + cos(theta) * y - 400 < 217 :

Este código, obviamente, no es muy legible porque resulta muy difícil determinar el significado de la prueba realizada. Sin embargo, creando una variable Xpantalla (correspondiente a una coordenada de pantalla del cálculo x + cos(theta) * y - 400) y una variable LARG_VISUAL (correspondiente al ancho del área de visualización), obtenemos:

# coordenadas del protagonista en pantalla 
Xpantalla = x + cos(theta) * y - 400 
 
# ancho de área de visualización 
LARG_VISUAL = 217 
 
if 0 < Xpantalla < LARG_VISUAL : # prueba si el protagonista está 
visible en la pantalla

El segundo caso, donde existen varias variables para describir una misma noción, parece inconcebible. Sin embargo, esta situación puede ocurrir, he aquí hay un ejemplo. Para gestionar un conjunto de elementos, un programador puede decidir crear una variable NumElem indicando el número de elementos en el conjunto y otra variable EstaVacia que indicará si este conjunto está vacío. Técnicamente, este programa puede funcionar con esta opción de concepción. Sin embargo, la variable EstaVacia es redundante...

Las funciones

1. Identificar una función

a. Requisito

Si tiene la opción de configurar una función o copiar y pegar código existente para adaptarlo, la tentación de copiar y pegar será fuerte. He aquí por qué:

Escribir una función requiere el conocimiento de la sintaxis del lenguaje. A menudo es un punto de bloqueo. Si este es su problema actual, eche un vistazo al capítulo sobre las funciones.
Usted ha escrito un código funcional y piensa que copiar y pegar sigue siendo la mejor opción, mientras que escribir una función parece más arriesgado. Si este es el caso, eche un vistazo el uso de la palabra clave global y a las reglas para pasar argumentos en el capítulo de funciones.

b. Analizar o reestructurar código

Existen dos enfoques:

Usted Intenta estructurar su programa antes de escribirlo haciendo un borrador en papel. Este enfoque tiene la ventaja de que le obliga a tomarse un tiempo para pensar con calma. Sin embargo, sea cual sea su experiencia en programación, solo podrá identificar del 50 % al 90 % de la estructura del programa; el código no está completo. Por lo tanto, será necesario embarcarse en la implementación y descubrir los eventos imprevistos a lo largo del tiempo haciendo evolucionar el diseño del programa si fuera necesario.
Prefiere escribir código directamente. En general, los principiantes prefieren codificar porque quieren llegar rápidamente a un resultado tranquilizador para saber si se están moviendo en la dirección correcta. Estos producen muchas líneas de código y en un segundo paso reestructuran su código creando funciones.

Sea cual sea el enfoque elegido, estudio en papel o codificación directa, en todo caso será necesario que sepa cómo cambiar la estructura de su código. Nos vamos a poner en la situación en la que se han escrito muchas líneas de código y ahora tenemos que tratar de estructurarlas para remodelar el programa correctamente.

c. El enfoque equivocado

Se pueden escribir muchas líneas de código una tras otra sin llamadas a funciones. Cuando se quiere estructurar el código existente, el mal reflejo es seleccionar, un poco al azar, porciones de código para transformarlas en funciones. Este enfoque da algunas...

Estructura jerárquica de un programa

1. La cuestión (comprobar)

Cuando programamos, con demasiada frecuencia nos centramos en los pequeños problemas del momento: sintaxis, nombres de variables, precisión de las pruebas lógicas, implementación de algoritmos... En definitiva, estamos demasiado a menudo con la cabeza en el manillar y nos olvidamos de dar un paso atrás para tener una visión más amplia.

La mayoría de las veces, esto no será un problema porque escribimos programas cortos, de unas pocas docenas de líneas. Sin embargo, cuando empezamos a escribir un minijuego durante un proyecto, la aventura puede llevarnos a escribir de 200 a 500 líneas de código, o incluso más. Si no dedicamos un mínimo de energía a estructurar el programa, esto puede ser peligroso: el programa funcionará mal y los programadores terminarán sin saber manejar los errores.

Los programas largos, sin estructuración, sufren varios problemas:

El código que gestiona los detalles está al mismo nivel que el código que maneja aspectos más generales del programa. Esto hace que sea difícil de leer y entender.
Diferentes tratamientos están entrelazados. Así, cuando buscamos el lugar en el programa gestionando un punto concreto, encontramos líneas de código repartidas por todas partes. Esto no es bueno porque se vuelve muy difícil identificar y aislar todos los tratamientos, lo que lleva a una mala comprensión de cómo funciona el programa.
Los errores están presentes y su búsqueda es difícil. De hecho, en general, si tiene un error relacionado con el movimiento de PacMan, naturalmente se colocará al comienzo de la función DeplacePacman() y comprobará que los parámetros de esta función contengan valores correctos. A continuación, ejecutará línea por línea los diferentes procesos para detectar la aparición de algún error. En treinta líneas, la búsqueda es fácil. Sin embargo, si no ha escrito una función específica para esto, la primera y la última línea del procesamiento pueden cubrir una región de 200 líneas de código, incluido otros procesamientos, además de las llamadas...

Caso práctico - El juego del laberinto y las momias

1. Presentación

Le presentamos las etapas de análisis de un juego de laberinto hechas por una programadora principiante a la que llamaremos Irene. Descubriremos sus elecciones de diseño, análisis, pruebas y las decepciones de nuestra nueva amiga. El objetivo de este capítulo es mostrar que una reflexión sobre el diseño de un programa es un punto importante y que se construye en sucesivas fases de análisis y de investigación. Este caso práctico permite, así, aplicar los principios introducidos al principio del capítulo.

a. Desde el punto de vista del principiante

Si configura un proyecto importante yuxtaponiendo piezas de código y esperando que salga bien, desafortunadamente, no saldrá bien. De hecho, este enfoque conduce a la falta de organización y de estructura en su proyecto. Este último terminará pareciendo un pulpo con tentáculos, los errores que encuentre serán muy difíciles de solucionar y la evolución de su programa el parecerá una tarea insuperable.

Irene intentará establecer opciones de diseño, dividir su proyecto en partes independientes, representar datos de la manera más adecuada posible y no mezclar los diferentes niveles de jerarquía en su programa. Irene tendrá muchas buenas ideas, pero encontrará que permanecen presentes muchas áreas grises incluso cuando ya ha pasado mucho tiempo detectando trampas. Por lo tanto, tendrá que repensar su modelo de diseño, tratar de mejorarlo sin elegir una solución que sea demasiado compleja para su nivel.

A veces, Irene tendrá que llamar a su amiga Judith para pedirle ayuda cuando encuentre problemas que no podrá solucionar. De hecho, a veces es muy difícil encontrar el origen de un error, incluso si el código parece simple y que esté escrito correctamente. Será necesario tener una opinión externa.

Este capítulo original presenta la definición de un juego bastante simple pero relativamente largo, hecho por un programador principiante o experimentado. Muchos principiantes creen que hay que tener la intuición correcta desde el primer momento. De lo contrario, concluyen que no están hechos para convertirse en buenos programadores. Otros...

Concepción de un programa