Projet : travail en binômes

Le projet est en principe un travail à faire en binômes. Il est important dans ce cadre d'adopter une bonne discipline, notamment pour le partage de vos fichiers. Vous trouverez dans ce document quelques indications et recommandations à ce sujet.

Travail à «quatre mains»

Dans certains cas, il sera probablement plus profitable de travailler en même temps, soit en étant à deux devant un même ordinateur (typiquement en salle de TP), soit en partageant un écran à distance.

Un premier membre du groupe tape au clavier, tandis que l'autre l'assiste. Pour qu'une telle organisation soit efficace et profitable à chacun, il convient de respecter quelques règles :

Les avantages de cette façon de travailler sont que :

  1. les membres du binôme peuvent s'aider mutuellement à comprendre le projet et à trouver des solutions aux problèmes rencontrés,
  2. le projet a plus de chances d'être correct lorsqu'il a été écrit par deux personnes réfléchissant simultanément que par une seule,
  3. chaque membre du binôme connaît et comprend à tout moment la totalité du projet et en a ainsi une meilleure vue d'ensemble.

Travail «en parallèle»

Si le travail «à quatre mains» est a priori encouragé (en tout cas pour commencer le projet), vous avez la possibilité aussi de paralléliser certaines tâches. Avec une telle organisation, il est très important de trouver une bonne répartition du travail, qui soit à la fois efficace et juste. Il faudra notamment avoir bien avoir compris la chronologie des tâches et leur inter-dépendances et établir un calendrier de qui intervient sur quoi, à quel moment et de quand resynchroniser et tester le tout.

Partage du code

Dans tous les cas vous serez amenés à échanger du code entre vous. Plusieurs solutions à ce problème existent, et nous vous en proposons deux ci-dessous :
  1. l'utilisation d'un système de partage de fichiers « dans le nuage »,
  2. l'utilisation d'un système de gestion de versions (avancé).

La première solution est recommandée car beaucoup plus simple. Dans tous les cas vous devrez faire preuve de rigueur pour éviter de fausses manœuvres et devrez bien communiquer entre vous.

Partage des fichiers dans le nuage

De nombreux systèmes de stockage de fichiers « dans le nuage » existent (Dropbox, Google Drive, iCloud Drive, etc.) et permettent à plusieurs utilisateurs de partager un dossier.

Un dossier partagé peut être utilisé par les membres d'un groupe pour synchroniser leur travail. L'idée est simple : chaque membre possède une version « privée » du projet sur son ordinateur, qui ne se trouve pas dans le dossier partagé (sur le nuage). La totalité du développement se fait dans ce dossier privé, et lorsqu'un fichier (contenant p.ex. une classe) est terminé et prêt à être partagé, il est copié dans dans le dossier partagé, d'où l'autre membre peut le copier dans son dossier privé.

Avec une telle organisation, il existe à tout moment trois versions, généralement différentes, du projet : une par membre du groupe, stockée dans un dossier privé, et la version commune, stockée dans le dossier partagé.

Il faut bien prendre garde à ne pas faire de fausse manœuvre lors de la copie de fichiers entre ces différentes versions.

Maintenir un petit fichier texte d'historique des modifications sur le dossier partagé peut être une bonne idée: à chaque fois que vous copiez un fichier de votre dossier privé vers le dossier partagé sur le nuage, écrivez un petit commentaire de ce que vous avez fait dans le fichier «historique», par exemple: 
     10.3.2022: fichier Collider.cpp ajout des operateurs + et =
et avisez votre binôme de vos modifications.

Notez que certains systèmes de partage de fichiers, entre autres Dropbox, permettent d'accéder aux fichiers récemment effacés, ou aux anciennes versions de fichiers existants. Cette fonctionnalité peut être fort utile en cas de mauvaise manipulation.

Vous prendrez soin à ce que votre dossier partagé ne soit accessible qu'aux deux membres du binôme.

Utilisation d'un gestionnaire de version (avancé)

Une autre solution existe au problème du partage du projet, plus propre et plus sûre, mais aussi considérablement plus difficile à mettre en œuvre : l'utilisation d'un système de gestion de version (version control system en anglais).

Un système de gestion de version est un programme permettant à plusieurs personnes de travailler en commun sur un projet. L'idée de base n'est pas très différente de celle consistant à utiliser un dossier partagé pour communiquer. Toutefois, avec un système de gestion de version, le transfert des fichiers entre les dossiers contenant les différentes versions du projet est faite par le système de gestion de version lui-même, ce qui réduit le risque de fausse manœuvre.

L'utilisation d'un système de gestion de version sort du cadre de ce cours et aucun soutien n'est en principe offert par l'équipe du cours en cas de problème avec un système de gestion de version, quel qu'il soit. Gérer de tels soucis peut en effet être chronophage et porter préjudice à l'aide que nous souhaiterions apporter sur le projet lui-même.

Nous conseillons néanmoins aux groupes qui restent désireux d'utiliser un système de gestion de version de choisir git. Il s'agit du système de gestion de version le plus en vogue actuellement, ce qui présente plusieurs avantages, en particulier une documentation assez abondante — dont l'excellent livre Pro Git, disponible gratuitement — et plusieurs programmes facilitant son utilisation. Cela dit, il faut noter que l'utilisation de git est généralement complexe, même pour les personnes averties.

A l'EPFL, l'association GNU Generation met à disposition une instance de la plateforme GitLab (voir un petit guide ci-dessous), qui permet aux membres d'un groupe de partager leur travail. GitLab offre la possibilité d'avoir un entrepôt git privé, c-à-d visible uniquement à certaines personnes. Cela est très important pour ce cours, étant donné que vous ne devez jamais partager publiquement votre travail, sous peine d'être accusé de plagiat.

git est donc un outil complexe et très puissant, qui s'il est utilisé à bon escient, est très utile. Mal utilisé, il peut en revanche rapidement vous faire perdre un temps précieux (voir des contenus de fichiers :-/). Vous trouverez dans ce document, git-sv-gitlab.txt, un petit résumé (informel et fourni à bien plaire) des bases fondamentales à connaître pour utiliser une dépôt GitLab en ligne de commande. Il est impératif d'éviter de partager du code compilé (dossiers build par exemple) ou non texte (.pdf par exemple ou des binaires).Partager de tels fichiers est souvent source de conflits lors des opérations de pull et push. Le meilleur moyen de vous en prémunir est d'utiliser un fichier .gitignore à la racine du répertoire sous git, et dont voici un petit exemple de contenu.