---
title: "Projets, CM2"
date: 2016-05-18
---

# Conception d’un logiciel

## Quoi-qu’est-ce ?

- « plan du code » (diagrammes de classes...)
- au début du projet, permet de prévoir le code à écrire
- pendant le projet, permet de suivre l’avancée du projet
- à la fin du projet, permet de documenter le code (maintenance)

$\rightarrow$ doit correspondre aux fonctionnalités prévues et au code réel

## En pratique

- représentation graphique + explications
- si possible, utiliser un formalisme classique (UML)
- utiliser plusieurs niveaux d’abstraction (vue d’ensemble, vues détaillées)

## Étape de conception

- étape **très importante**, à faire avant le développement
- évite ”d’avoir à tout casser” au cours du développement
- permet de répartir le travail et de planifier plus finement

## Quelques conseils

- faire simple, logique, classique (MVC, design patterns...)
- granularité : ne pas trop détailler sauf si important/incertain/complexe
- vérifier **a priori** que la conception permet d’implémenter les fonctionnalités prévues dans le cahier des charges


# Développement d’un logiciel

## Méthode pour écrire du code

- comprendre le travail à faire (fonctionnalité/classe à implémenter)
- découper en étapes et les ordonner
- implémenter (coder, compiler, tester) étape par étape

## Conseils sur le développement en équipe

- faire le point régulièrement : travail fait, travail à faire
- répartir le travail de façon à éviter les conflits (fichiers différents)
- commits réguliers, branches si nécessaire
- faire attention à respecter le cahier des charges et la conception

## Programmation en binômes

- principe :
    - un secrétaire + un relecteur **sur une même machine**
    - les deux participent activement
    - changer les rôles fréquemment
- intérêts :
    - moins d’erreurs
    - réflexions complémentaires
    - motivation, convivialité (ou pas, mais bon...)
- à utiliser quand le travail n’est pas complètement trivial (donc tout le temps pour les projets L3)

## Tests unitaires

- souvent : test « avec un printf » $\rightarrow$ pas bien
    - principe des tests unitaires :
    - écrire des petites fonctions de test en même temps que le code
    - compiler toutes les fonctions de test dans un programme de test
    - exécuter le programme de test
    - vérification et non-régression automatiques
- attention : détection d’erreurs $\neq$ preuve

$\rightarrow$ à utiliser pour les modules de base (traitement de données) voire plus

## Programmation par pseudo-code

- principe :
    - commencer par écrire le pseudo-code de l’algo en commentaire
    - traduire chaque ligne de pseudo-code en code réel
    - laisser le pseudo-code en commentaire
- intérêt :
    - code plus facile à écrire
    - code plus facile à relire

$\rightarrow$ très utile quand le code à écrire n’est pas trivial

## Gestion d’erreurs

- assertions
- logs
- codes de retour, variables d’état
- exceptions

$\rightarrow$ problème difficile

$\rightarrow$ se mettre d’accord sur la façon de faire au début du projet

## Conventions de code

- formatage du code, nommage des variables...
- conventions à définir et à respecter au niveau du projet
- permet d’avoir un code plus facile à lire
- utiliser des conventions classiques ou les expliciter dans la documentation

## Exemple de conventions de code C++

- notation dromadaire
- un nom de classe commence par une majuscule :
```cpp
class Event ...
```
- préfixe _ pour les attributs :
```cpp
std::string _summary ;
```
- préfixe ptr pour les pointeurs :
```cpp
icalcomponent * _ptrIcal ;
```
- un nom de fonction commence par un verbe :
```cpp
void updateDataFromIcal();
icalcomponent * getPtrIcal() const ;
```
- maximum 80 caractères par ligne
- ...

## Quelques outils de développement à décider

- langages, bibliothèques...
- outils de compilation, test, déploiement
- outils de gestion de code source (git, svn...)
- outils de gestion de projets (github, redmine, trac, sourceforge...)


# Gestion de code source avec git

TODO

```
A -- B -- C
           \
            D -- E
```

![](github_accueil.png)

* * * *

![](github_issue_3.png)

* * * *

![](github_issue_3.png)

* * * *

![](github_milestone_2.png)

* * * *

![](github_collaborateurs.png)  

* * * *

![](github_issue_4.png)

* * * *

![](github_milestone.png)

* * * *

![](github_issue_2.png)      

* * * *

![](github_issue.png)

* * * *

![](github_nouveau_projet.png)

* * * *





```console
$ git clone https://juliendehos@github.com/juliendehos/projet_l3
Clonage dans 'projet_l3'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Dépaquetage des objets: 100% (3/3), fait.
Vérification de la connectivité... fait.
```

```console
$ git add proto.cpp Makefile 

$ git status
Sur la branche master
Votre branche est à jour avec 'origin/master'.
Modifications qui seront validées :
  (utilisez "git reset HEAD <fichier>..." pour désindexer)

	nouveau fichier : Makefile
	nouveau fichier : proto.cpp

$ git commit -am "close #1"
[master eab4260] close #1
 2 files changed, 9 insertions(+)
 create mode 100644 Makefile
 create mode 100644 proto.cpp

$ git push
Password for 'https://juliendehos@github.com': 
Décompte des objets: 4, fait.
Delta compression using up to 4 threads.
Compression des objets: 100% (3/3), fait.
Écriture des objets: 100% (4/4), 447 bytes | 0 bytes/s, fait.
Total 4 (delta 0), reused 0 (delta 0)
To https://juliendehos@github.com/juliendehos/projet_l3
   bd1f597..eab4260  master -> master
```


# Gestion de projets avec github

TODO


# Travail à réaliser

## Au début du projet

- créez des comptes et un dépôt sur [github](https://github.com)
- faire une conception prévisionnelle du logiciel
- faire un planning prévisionnel (et les tickets correspondant sur github)

## Tout au long du projet

- utiliser git pour réaliser le projet (code, documentations, cahier des charges...)
- utiliser github pour suivre le déroulement du projet
- faire le point régulièrement pour mettre à jour la conception du logiciel et la répartition du travail