Name: Python Apprenez à développer des projets ludiques (2e édition)
Rating: 4.75 (4 reviews)

Présentation

Lorsque vous effectuez des exercices de programmation, des travaux pratiques ou des tutoriels, le travail à accomplir reste relativement cadré. Par exemple, lorsque le formateur vous demande de coder une fonction, il vous décrit précisément ses paramètres ainsi que le résultat attendu. Il vous reste à établir la logique et à mener les traitements correctement.

En revanche, en codant un projet personnel ou un projet scolaire, plus le projet avance, plus vous rencontrez de problèmes : des erreurs étranges apparaissent et qui plus est, par intermittence ; l’ajout de fonctionnalités devient difficile et relire le code s’avère ardu.

Pourquoi une personne capable de mettre en place 20 fonctions de 10 lignes chacune se retrouve-t-elle en difficulté sur un projet de 200 lignes ? Ces deux challenges semblent de prime abord similaires.

Pourtant, il n’en est rien. Il y a en effet une différence cruciale entre savoir faire des exercices courts et mener à bien un projet long : il s’agit de la capacité à concevoir un programme, à l’organiser et à le structurer. Cette compétence ne s’apprend pas toujours dans les cursus de formation, ceci généralement par manque de temps.

Ainsi, dans ce chapitre, pour vous permettre de réaliser des projets longs, nous allons vous transmettre les grands principes de la conception d’un programme.

Principes de conception

1. Les trois grands principes : Identifier/Structurer/Améliorer

Pour concevoir un projet informatique long, tout programmeur est amené à respecter les trois principes suivants :

Identifier les données et les actions/traitements.
Structurer les données et les actions/traitements.
Améliorer ses choix de conception.

Ces trois grands principes ne s’articulent pas autour des techniques de codage. En effet, réaliser un projet de plusieurs heures nécessite d’autres compétences que la programmation.

Les programmeurs doués rencontrent une difficulté car ils ont tendance à coder vite, sans prendre le temps de réfléchir à la conception, ce qui produit du code désorganisé. S’apercevant que leur conception est bancale, ces programmeurs vont reformuler les différentes parties de leur programme en espérant améliorer leur conception. Malheureusement, sans prendre davantage de recul, ils transforment leur conception bancale en une autre conception bancale, tout aussi peu satisfaisante.

Le secret pour concevoir un programme long est de prendre de la hauteur et du recul. Vous devez maintenant réfléchir en considérant les besoins et les objectifs demandés. Prendre ce temps de réflexion implique de s’éloigner momentanément du codage et ce n’est pas facile pour tout le monde.

Les trois principes proposés vont vous aider à réaliser la conception la plus adéquate possible ; nous les détaillons ci-dessous :

Identifier les données et les actions/traitements constitue le premier principe....

Les variables

1. Identifier les variables

a. Règle : 1 notion = 1 variable

Lorsque vous listez les informations nécessaires pour effectuer un traitement, vous listez, sans vous en rendre compte, les variables dont vous avez besoin. Vous devez donc respecter la règle suivante :

Chaque notion doit être représentée par une variable

Prenons un exemple. Si vous devez créer un clone du jeu PacMan, il va falloir afficher les différents éléments du jeu à l’écran. Pour cela, il faut connaître la position de PacMan, des quatre fantômes et des bonus. Ainsi, pour avoir ces informations à disposition, il est nécessaire de créer des variables pour stocker les positions des éléments du jeu comme xPacMan et yPacMan…

Lorsque l’on affirme que chaque notion doit être représentée par une variable, cela sous-entend qu’il ne faut pas en choisir zéro ou plusieurs !

Dans le premier cas, l’absence de variable se produit lorsqu’un programmeur écrit un calcul à l’intérieur d’un autre traitement, comme dans l’exemple suivant :

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

Ce code est évidemment peu lisible car il est très difficile de déterminer la signification du test effectué. Par contre, en créant une variable Xecran (correspondant à une coordonnée écran issue du calcul x + cos(theta) * y - 400) et une variable LARG_AFF (correspondant à la largeur de la zone d’affichage), on obtient :

# coordonnée du héros à l'écran 
Xecran   =...

Les fonctions

1. Identifier une fonction

a. Prérequis

Si vous avez le choix entre mettre en place une fonction ou copier-coller du code existant pour l’adapter, la tentation du copier-coller sera forte. Voici pourquoi :

Écrire une fonction nécessite de connaître la syntaxe du langage. C’est souvent un point bloquant. Si c’est votre problème actuel, révisez le chapitre sur les fonctions.
Vous avez écrit un code fonctionnel et vous pensez que le copier-coller reste la meilleure option alors qu’écrire une fonction vous semble plus hasardeux et plus risqué. Si tel est le cas, révisez l’utilisation du mot-clé global et les règles de passage des arguments dans le chapitre sur les fonctions.

b. Analyser ou restructurer le code

Deux approches existent :

Vous essayez de structurer votre programme avant de l’écrire en faisant un brouillon sur papier. Cette approche a l’avantage de vous obliger à prendre un peu de temps pour réfléchir posément. Cependant, quelle que soit votre expérience en développement, vous n’arriverez à identifier que 50 % à 90 % de la structure du programme, ce qui reste incomplet finalement. Il faudra donc se lancer dans l’implémentation et découvrir les imprévus au fil de l’eau en faisant évoluer la conception du programme si besoin.
Vous préférez coder directement. Généralement, les débutants préfèrent coder pour se rassurer car ils souhaitent parvenir rapidement à un résultat pour savoir s’ils avancent dans la bonne direction. Ils produisent...

Structure hiérarchique d’un programme

1. La problématique

Lorsque nous programmons, nous nous concentrons trop souvent sur les micro-problèmes du moment : syntaxe, noms des variables, exactitude des tests logiques, mise en place des algorithmes… Bref, nous sommes trop souvent la tête dans le guidon et nous oublions de prendre du recul.

La plupart du temps, cela ne posera aucun problème car nous écrivons des programmes courts, de quelques dizaines de lignes. Néanmoins, lorsque l’on se lance dans l’écriture d’un mini-jeu durant un projet, l’aventure peut nous amener à écrire 200 à 500 lignes de code, voire plus. Si l’on ne consacre pas un minimum d’énergie pour structurer le programme, cela va être dangereux : le programme va dysfonctionner et les développeurs vont finir par ne plus savoir comment gérer les erreurs.

Les programmes longs, sans structuration, souffrent de plusieurs problèmes :

Le code gérant des détails se trouve au même niveau que du code gérant des aspects plus généraux du programme. Cela rend difficiles la lecture et la compréhension.
Différents traitements s’entremêlent. Ainsi, lorsque l’on cherche l’endroit dans le programme gérant un point spécifique, on trouve des lignes de code éparpillées un peu partout. Cela n’est pas bon car il devient très difficile d’identifier et d’isoler l’ensemble des traitements, ce qui conduit à une mauvaise compréhension du fonctionnement du programme.
Des bugs sont présents et leur recherche...

Cas pratique - Le jeu du labyrinthe et des momies

1. Présentation

Nous présentons les étapes d’analyse d’un jeu de labyrinthe par un programmeur débutant que nous appellerons Tom. Nous allons découvrir ses choix de conception, ses analyses, les tests et les déceptions de notre nouvel ami. Le but de ce chapitre est de montrer qu’une réflexion sur la conception d’un programme est un point important et qu’elle se construit par phases successives d’essais et de recherche. Ce cas pratique permet ainsi de mettre en œuvre les principes introduits en début de chapitre.

a. Du point de vue du débutant

Si vous mettez en place un projet important en juxtaposant des morceaux de code et en espérant que cela se passe bien, malheureusement, cela ne va pas bien se passer. En effet, cette approche induit un manque d’organisation et une absence de structure dans votre projet. Ce dernier finira par ressembler à une pieuvre tentaculaire, les bugs que vous rencontrerez seront très difficiles à corriger et faire évoluer votre programme vous semblera une tâche insurmontable.

Tom va essayer de mettre en place des choix de conception, de découper son projet en parties indépendantes, de représenter les données de la manière la plus adéquate possible et de ne pas mélanger les différents niveaux de hiérarchie dans son programme. Tom aura beaucoup de bonnes idées, mais il s’apercevra que beaucoup de zones d’ombre restent présentes même en ayant déjà passé beaucoup de temps à repérer les pièges. Il devra donc repenser...