Votre rendu sera un unique dépôt Git. Vous devrez définir et justifier l'organisation des branches, l'utilisation ou non de branches dev, de branches liées aux fonctionnalités, de branches distinctes pour les versions, ou l'utilisation de tags.
Testez le code game_target_v3.py
Dans le cas ou le sujet ne vous paraitrez peu clair ou erronné, proposez des changements en les justifiant pour pouvoir répondre aux questions . Même si rien ne marche, remplissez au mieux les attendus en étant clair sur ce qui marche et ce qui ne marche pas (cf la suite)
Important
Soyez clair dans le README de votre main du rendu principal, où je dois trouver les differentes versions attendues
Pour chaque Version, vous devrez :
- Expliquer ce qui marche et ce qui ne marche pas
- Joindre des copies d'écran, du résultats des scripts exécutés
- Expliquer l'usage de venv, dans votre cas (NE PAS JOINDRE DE REPERTOIRE Venv dans votre git ou de fichiers temporaires)
- Coder la ou les classes et le package associé et les déposer sur test Pypi
- Mettre en place des tests, les plus complets possibles en utilisant unitest : en particulier, comment gérez-vous les éventuelles erreurs ?
- Afficher les choix sur le code final de la classe si vous avez dû faire des changements : Affichez votre score et le retour de Pylint.
- Associer au projet gitlab le README le plus complet possible
- Faire un gros effort sur les commentaires : utilisez intensivement les docstrings.
- Proposer l'installation du paquet à partir de gitlab avec une procedure dans le README
- Proposer l'installation du paquet à partir de test pypi avec une procédure dans le README
- Automatiser les phases de test et de création du .whl sur GitLab avec un fichier ci
- Faire apparaitre votre arbre de commit dans le README, en expliquant les choix faits sur les branches et les tags
Le but est de cette version est de mettre en forme le code donné pour en créer un package (logique setup.py ou éventuellemnt pyproject.toml) en modifiant a minima le code donné (même si il vous semble incorrect ou peu pertinent). On mettra aussi en place toute la logique de test unitaires
Important
on relira l'attendu précédent. Pour chaque Version, vous devrez : ...
Le code proposé présente beaucoup d'améliorations possibles . En particulier, le fait de modifier directement la grille (grid) sans passer par une méthode est problématique ( ce qui apporterait des sécurités) . Ensuite le fait que le code suivant ne genere pas d'erreur est aussi problematique
if __name__ == "__main__":
# Création de la grille et du robot
grid = Grid(5, 5)
robot = Robot(10, 10)
# Création du jeu avec l'option d'affichage de la grille et une limite d'étapes
game = Game(grid, robot, max_steps=1000, show_grid=False)
# Exécution des tours de jeu jusqu'à ce que le robot touche la cible ou que la limite d'étapes soit dépassée
while not game.run_turn():
pass
# Vérification si le robot a atteint la cible ou non et affichage du message approprié
if game.target_reached:
print("Félicitations ! Le robot a atteint la cible en {} étapes.".format(game.steps))
else:
print("Le robot n'a pas réussi à atteindre la cible dans le nombre maximum d'étapes.")Proposer des correctifs à ces problèmes et d'autres problème que vous auriez constaté . Il est imporrtant que tous les changements se reperercutent sur les tests unitaires . N'hésitez pas à améliorer au passage vos tests unitaires si il n'était pas suffisemment complet sur la version 1.
Important
on relira l'attendu précédent. Pour chaque Version, vous devrez : ...
On souhaite définir différentes stratégies de déplacement du robot. Proposez en plus de la stratégie de base aléatoire , 2 autres stratégies (qui peuvent aussi ou pas comporter une part d'aléatoire). A vous de proposez une facon pertinente de changer quelle stratégie est utilisé, cela doit pouvoir être défini dans le "main" sans avoir à changer à la main le code des différentes classes.
Important
on relira l'attendu précédent. Pour chaque Version, vous devrez : ...