Préparation au projet : Développement d’une application

Cette séance est dédiée à la préparation de votre projet SAÉ 1256, qui consiste en la création d’une application. Le projet intègre trois ressources principales : Qualité de développement (R203), IHM (R202) et DOO (R201).

Prise en main du sujet¶

S’il y a des éléments techniques du sujet que vous n’avez pas encore vu, pas de panique, c’est normal puisque nous débutons le semestre. Vous aurez l’occasion de les découvrir prochainement. Si vous avez des questions spécifiques sur le sujet, réservez-les pour le premier amphi avec M. La, M. Ravenet et M. Martin.

Constitution des groupes de travail¶

Git¶

Création du dépôt¶

Une fois que votre groupe est formé, le dépôt Git pour le projet doit être créé par un seul membre du groupe. Deadline pour la création du dépôt : vendredi 21/02 à 23h59.

Organisation du dépôt¶

Il est essentiel d’organiser correctement votre dépôt Git pour éviter le mélange des fichiers de rendus. Créez des sous-dossiers spécifiques pour chaque type de rendu (exemple : un dossier pour les maquettes, un autre pour UML et modèle Java, etc.).

Travail collaboratif¶

Apprenez à travailler en équipe avec Git. Il est important d’éviter les conflits de fusion, en particulier lorsque plusieurs membres du groupe travaillent sur le même fichier.

Découpage du code

Organisez-vous pour découper votre code en différentes classes et fichiers. Chaque membre peut travailler sur une partie distincte du code sans risquer de conflits. Utilisez un découpage de code modulaire, que vous pourrez fusionner ultérieurement si nécessaire.

Par exemple, ici nous avons un fichier Car.java

Car.java

public class Car {
    private String make;
    private String model;

    public Car(String make, String model) {
        this.make = make;
        this.model = model;
    }

    public void displayDetails() {
        System.out.println("Car Make: " + make);
        System.out.println("Car Model: " + model);
    }
}

qui est utilisé par le fichier Main.java dans le même répertoire.

Main.java

public class Main {
    public static void main(String[] args) {
        Car myCar = new Car("Toyota", "Corolla");
        myCar.displayDetails();
    }
}

Si les deux fichiers ne sont pas dans le même répertoire et sont structurés de la façon suivante,

/vehicles
    Car.java
Main.java

alors il suffit d’ajouter import vehicles.Car; au début de Main.java.

Ne push pas de bugs !

Vous n’avez pas encore vu les branches Git, donc voici une règle simple pour le travail en équipe : si votre code ne compile pas, ne le push pas.

Lorsque vous commencerez à écrire des tests : si un code ne passe pas un test, ne le push pas non plus.

Si vous avez besoin d’aide pour déboguer, commentez la partie du code problématique en expliquant le bug, puis push ces commentaires.

Même lorsque vous maîtriserez les branches Git, il restera essentiel de ne pas push de bugs sur la branche principale. Utilisez une branche de développement et décrivez clairement le problème en commentaire.

Dans les prochains semestres, vous découvrirez l’intégration continue, un système qui testera automatiquement chaque modification à chaque commit et qui vous empêchera même de push du code contenant des erreurs !

Résolution de conflits¶

Vous serez certainement amené à rencontrer des conflits. Voici un tutoriel simple pour vous aider à résoudre ces conflits dans le terminal, que vous travailliez seul ou en équipe. Des explications plus détaillées sur la résolution de conflits seront fournies dans le cours de Qualité de développement.

Pour commencer, créez le fichier suivant.

conflict.md

# Git Conflict Resolution

Let's explore how to resolve conflicts in Git.

## Merging Without Conflicts

Another member should add some content here:

Now, add some content locally without pulling the latest changes from GitLab:

## Merging With Conflicts

Another member should add some content here, then you should add different content locally without pulling the latest changes from GitLab:

Synchronisez votre dépôt local avec le dépôt distant.

Merge simple¶

Nous allons commencer par un exemple où le même fichier a été modifié de manière différente, mais les modifications concernent des sections de code distinctes et peuvent être fusionnées sans conflit.

Si vous êtes en équipe, un autre membre doit synchroniser son dépôt local pour modifier conflict.md. Si vous êtes seul, ouvrez le Web IDE de GitLab. Ajoutez le texte suivant :

Another member should add some content here: Hello

Commit et push vos modifications pour avoir cette nouvelle version de conflict.md sur GitLab.
Sans avoir récupéré ces nouvelles modifications sur votre dépôt local, ajoutez le texte suivant dans le fichier conflict.md de votre répertoire de travail :

Now, add some content locally without pulling the latest changes from GitLab: Hi

Lorsque vous effectuerez un push, une erreur s’affichera pour vous indiquer qu’il y a des changements sur le dépôt distant qu’il vous faut récupérer dans votre dépôt local avec un pull. Si vous effectuez un pull, vous recevrez à nouveau la même erreur concernant les branches divergentes.
Exécutez la commande suivante.

git merge origin/main

Git fera un add automatiquement et vous proposera d’écrire un message de commit pour l’opération, avec un message auto-généré déjà pré-rempli. Vous pouvez modifier ce message si vous le souhaitez.

Vous pouvez vérifier que conflict.md contient bien les deux modifications.

Finissez la résolution avec git push.

Merge avec conflits¶

Dans l’exemple précédent, nous avons vu une fusion où les modifications apportées aux deux versions du même fichier ne se chevauchaient pas, ce qui a permis à Git de fusionner automatiquement les changements.

Cette fois, nous allons refaire la même opération en modifiant conflict.md de la façon suivante :

Un autre membre de l’équipe (ou vous-même à partir du Web IDE de GitLab) doit modifier le fichier et synchroniser avec GitLab de la façon suivante :

Another member should add some content here, then you should add different content locally without pulling the latest changes from GitLab: Hello

Localement, vous allez écrire :

Another member should add some content here, then you should add different content locally without pulling the latest changes from GitLab: Hi

Lorsque vous effectuerez un push puis un pull, vous allez rencontrer les mêmes erreurs qu’avant. Cette fois, git merge renvoie aussi une erreur :

Auto-merging conflict.md
CONFLICT (content): Merge conflict in conflict.md
Automatic merge failed; fix conflicts and then commit the result.

Ouvrez conflict.md dans un éditeur de texte de base. Vous allez voir les lignes suivantes.

<<<<<<< HEAD
Another member should add some content here, then you should add different content locally without pulling the latest changes from GitLab: Hi
=======
Another member should add some content here, then you should add different content locally without pulling the latest changes from GitLab: Hello
>>>>>>> origin/main

Entre <<<<<<< HEAD et ======= se trouve la version courante sur le dépôt local et la version du dépôt distant entre ======= et >>>>>>> origin/main.

Remplacez ce bloc de texte par la version finale de votre choix (qui peut différer des deux versions proposées). Par exemple :

Another member should add some content here, then you should add different content locally without pulling the latest changes from GitLab: Haha

Add, commit et push la version finale.

Gestion de projet¶

Dès le début, organisez-vous pour bien répartir les tâches.

Bien que la gestion de votre projet ne fasse pas l’objet d’une évaluation spécifique, les encadrants vérifieront régulièrement votre avancement et l’équilibre du travail au sein du groupe. L’implication de chaque membre est cruciale pour le succès du projet.

Conclusion¶

Une fois la préparation terminée, vous passerez immédiatement à la phase de rendu des maquettes et des tables fonctionnelles de l’IHM. Commencez à réfléchir à vos idées pour le projet et à remplir votre fichier README.

Practical Sessions

TP7: Review

Projet SAÉ 1256

Notation pour le projet