Collaboration à la conception d’applications¶

Introduction¶

Présentation du Cours¶

Objectif du cours¶

  1. Initier l’étudiant à la collaboration en équipe de développement d’applications et à la méthodologie de développement.

  2. Fait suite au cours portant sur le développement d’objets intelligents et prépare l’étudiant au projet intégrateur

Les 4 choses à apprendre...¶

  1. git: sans git notre vie est triste

  2. Introduction à la conception d’applications : parce qu'il faut

  3. Méthode Agile: Pour être trendy

  4. Conception générale et détaillée: Parce que nous aimons le code.

Lien principal¶

https://all-dressed-programming.com/courses/420-320-ah/

Présentation de l'Enseignant¶

didier amyot¶

  • Étudié en mathématiques

  • Programmeur avant toutes choses

    • Python

    • Java

    • Clojure

    • Go

    • Rust

    • JavaScript/TypeScript

  • Travaillé à trop de places.

  • $4^{ime}$ cours que j'enseigne

Présentation des Étudiants¶

Étudiants¶

  • Votre nom
  • Vous étudiez en quoi
  • Vous aimez quoi
  • Language de programmation préféré

Présentation des Objectifs Du Cours¶

Détails¶

  • Pondération 1-2-2

  • Comment me contacter (didier.amyot@collegeahuntsic.qc.ca)

  • Horaires - mercredi & vendredi de 13h00 à 16h00

  • Présence en classe

  • Évaluations

  • Plagiat (ChatGPT)

Collaboration à la conception d’applications¶

Git¶

Mise-en-place (aka setup)¶

Installation de git¶

https://git-scm.com/downloads

Vérification¶

▶ git --version
git version 2.42.0

Créer un compte github¶

  • https://github.com/

Ajouter votre nom à git¶

▶ git config --global user.name "Mona Lisa"

Vérification¶

▶ git config --global user.name
Mona Lisa

https://docs.github.com/en/get-started/getting-started-with-git/setting-your-username-in-git?platform=windows

Ajouter votre courriel à git¶

▶ git config --global user.email "mona.lisa@louvre.paris"

Vérification¶

▶ git config --global user.email
mona.lisa@louvre.paris

https://docs.github.com/en/get-started/getting-started-with-git/setting-your-username-in-git?platform=windows

Ajouter les alias commun..¶

▶ git config --global alias.co checkout
▶ git config --global alias.br branch
▶ git config --global alias.ci commit
▶ git config --global alias.st status

Vérification.¶

▶ git config --list
alias.ass=add
alias.br=branch
alias.co=checkout
alias.st=status
include.path=/nix/store/471bf9jb0fkh15n8kcjbfsnnak5njp14-hm_gitconfig
color.ui=auto
core.autocrlf=input
core.editor=vi
core.quotepath=false
gui.editor=kate
init.defaultbranch=main
pull.default=current
push.default=current
user.email=didier.amyot@gmail.com
user.name=didier amyot

Générer une clé ssh¶

  • https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent

  • https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key

Ajouter la clé publique ssh à github!¶

C'est quoi git?¶

Selon le site web officiel¶

Git is a free and open source distributed version control system designed to handle everything

from small to very large projects with speed and efficiency.

Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM

tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.

https://git-scm.com/

Selon wikipedia (anglais)¶

Git (/ɡɪt/)[8] is a distributed version control system that tracks changes in any set of computer files, usually used for coordinating work among programmers who are collaboratively developing source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows (thousands of parallel branches running on different computers)

Logiciel de gestion de versions - wikipedia¶

Un logiciel de gestion de versions (ou VCS en anglais, pour version control system) est un logiciel qui permet de stocker un ensemble de fichiers en conservant la chronologie de toutes les modifications qui ont été effectuées dessus. Il permet notamment de retrouver les différentes versions d'un lot de fichiers connexes.

Objectif¶

  • Savoir qui à changé le code source

  • Savoir quand le code source à changé

  • savoir pourquoi le code source à changé

Objectif (autre point de vue)¶

  1. Travailler ensemble

  2. Garder l'historique du projet

https://youtu.be/2ReR1YJrNOM

Le monde sans Git¶

Travailler en équipe¶

  1. partage le code par courriel ou dropbox

  2. l'historique du projet est gardé dans des fichier zip un peu partout

Reconcilliation du travaille¶

  1. Toute une équipe s'assoit à une table a café en fumant des cigarettes pour "merger le code"

TODO: Travail à merger¶

Walid¶

  • tp_001.zip
  • tp_002.zip
  • tp_003.zip

Haikel¶

  • tp.rar
  • tp_.zip

Manel¶

  • tp.zip
  • tp.1.zip

Git - l'idée géniale¶

On va travailler localement!¶

  1. Toute l'historique du projet sera gardé dans le projet. Un projet sous système de version se nomme un "répository"

  2. On utilisera un outil en ligne de commande git pour

    1. ajouter à l'historique

    2. chercher dans l'historique

    3. merger le répository locale avec d'autres répositories

Un projet git typique¶

projet-koala/
├─ .gitignore
├─ .git/
├─ src/
│  ├─ server.ts
├─ README.md

Mais nous ne sommes pas de anarchistes!¶

origin¶

  • On utilisera Github comme origin

  • Github deviendra le "source of all thruth" pour ce qui est dans le projet

  • Github deviendra la vitrine publique de notre projet

  • Chaque contributeur "pushera" ces changements sur github

  • Chaque contributeur "pullera" les changements des autres de github

Workflow¶

flowchart TD
    A[github]-- Pull/Push ---X[Manel]
    A[github]-- Pull/Push ---Y[Walid]
    A[github]-- Pull/Push ---Z[Haikel]
    A[github]-.- |Pull| U[didier]

Sur Github¶

  • On peut créer des "issues"

  • On peut rouler les unit tests automatiquement.

  • On peut même déployer automatiquement

CI/CD¶

continuous integration (CI) and continuous delivery

flowchart LR
    A[Programmeur]-.-> B["Github"]
    B-- GitHub\nActions -->C["Builder"]
    C-- GitHub\nActions --> D["Tester"]
    D-- GitHub\nActions --> E["Deployer"]

Git - Terminologie¶

Répository¶

  • Un dossier managé par git

  • Le dossier contient un sous dossier .git qui contient tout l'historique

Remote¶

  • Une source du code dans un lieu fort fort lointain (ex: github, gitlab)

  • d'habitude, il y a un seul remote qui se nomme origin

Commit¶

  • Un snapshot complet de tout le répo à un certain temps

  • Est identifié avec un hash

  • Contient le hash des parents

Branch¶

  • On peut travailler sur plusieurs features en parallel sur le même projet.

  • Une branch est un peu comme le commit le plus récent

  • La branche principale se somme usuellement main ou master

HEAD¶

  • Mot que git utilise pour dire "la branche courrante"

  • https://www.cduan.com/technical/git/git-1.shtml#heads

Merge¶

  • Former un nouveau commit à partir de plusieurs commit

  • La pluspart du temps, on merge un branche dans une autre branch

Git - Les commandes git de base¶

git clone <url>¶

  • Sert à cloner une projet.

  • Ça prend une copie complète d'un projet avec tout l'historique

On fait des changements¶

  • Parce que nous aimons cela!

  • Parce que c'est nécessaire

git status (git st)¶

  • On regarde l'état du répo local

  • On voit tous les changements

  • On peut utiliser git diff pour regarder les changements avec

git add <...files>¶

  • Les changements que nous voulons sauvegarder

  • Ici, nous ne "committons" pas encore les changements

  • Nous dissons, "Je pense que je devrait sauvegarder cela"

  • Les changements ajoutés sont dans le "staging area"

git commit -m "<Le message du commit>"¶

  • Là nous demandons à git de sauvegarder nos changements

  • Tous les changements "stagés"

git push¶

  • on upload nos changements sur un remote

  • on peut uploader nos sur une autre branche ou un autre remote avec git push <remote-name> <branch-name> (git push origin master)

Branches¶

C'est quoi une branche?¶

  • On peut travailler sur plusieurs features en parallel sur le même projet.

  • Une branch est un peu comme le commit le plus récent

  • La branche principale se somme usuellement main ou master

Créer une branch¶

  • Céer sur une nouvelle branche & change le "HEAD" sur la branch
git switch -c <branch-name>

Méthode pour les vieux¶

git checkout -b <branch-name>

Git status¶

  • git status met en évidence la branche sur laquel nous nous trouveons

Merger une branch¶

git merge <branch-name>

Pour merger une branche "remote"¶

git merge origin/<branch-name>

Merge conflicts¶

Lors d'un merge, si deux branches changent la même section¶

  1. Il y a une "merge conflict"

  2. C'est à vous de résoudre le conflit

Exemple d'un conflit¶

  • Des fois, c'est très difficil à faire

Collaboration à la conception d’applications¶

Introduction à la conception d’applications¶

Notes importants¶

  • Ce cours est un plagit du cours donnés par Anastasiya Basanets

  • Anastasiya.Basanets@collegeahuntsic.qc.ca

Le development d'application c'est n'importe quoi¶

Il y a une excellente source pour mettre de l'ordre dans ce tas de kakashka: https://neverworkintheory.org/

Cours¶

À quoi sert les différentes méthodes?¶

Beaucoup de types différents de logiciels :

  • Logiciel de base (système d'exploitation, pilotes)
  • Applications traditionnelles et web
  • Jeux vidéos
  • Logiciel scientifique et de recherche
  • Logiciel embarqué (sur circuit électronique)
  • Modules d'intelligence artificielle
  • Etc

Chaque logiciel est développé en utilisant une approche différente, qui demande réflexion!

Exemples¶

On ne programme pas de la même manière un jeu vidéo et un électrocardiogramme.

Jeux video¶

Livraison: Pression du marché (ex.: sortir pour Noel, pour une plateforme, pour devancer la compétition).

Impact d'un bogue: On fera un correctif (« patch »).

électrocardiogramme¶

Livraison: Préférable d’être en retard que de livrer un produit dangereux.

Impact d'un bogue: Dommages aux personnes

Exemples¶

On ne programme pas de la même manière un jeu vidéo et un électrocardiogramme.

Firefox version 1¶

Priorités du développement: Découvrir les besoins des clients, trouver des solutions, implémenter, et valider que cela correspond aux besoins, etc.

Firefox version 57¶

Priorités de la maintenance: Corriger les bogues, fermer les failles de sécurité, identifier des besoins émergents, assurer que l'architecture reste saine, etc.

À quoi sert les différentes méthodes?¶

Ainsi, dans un projet typique, entre 60% et 80% de l’effort consacré au logiciel a lieu après la livraison, soit avec la correction des bogues et la maintenance.

Le développement doit donc produire un logiciel maintenable, en plus de 4 défis majeurs.

Étapes de développement¶

Discipline Exemple d’activités
Exigences Définition du problème
Définition des exigences (spécifications)
Conception Conception architecturale
Conception détaillée
Implémentation Codage et débogage
Tests unitaires
Intégration et tests d’intégration
Tests Tests boîtes blanche (vérification)
Tests boîte noire (validation)
Déploiement Période de rodage (ajustement post-livraison)
Maintenance corrective (correction bogues)
Maintenance perfective (ajout de fonctionnalités)

Cycle de development¶

ss

Question 1¶

Pourquoi est-il important de penser à la maintenance du logiciel avant de commencer le développement ?

  1. Parce que la maintenance est la première étape du développement logiciel.
  2. Parce que la majorité du coût du logiciel provient de l'effort effectué durant la maintenance.
  3. Parce que la maintenance est l'étape où le code est écrit.
  4. Parce que nos logiciels sont toujours pleins de bogues et qu'il faut prévoir beaucoup de temps pour les corriger.

Question 2¶

Un logiciel n'est pas comme un bâtiment : il ne peut pas s'effondrer et tuer une personne. En conséquence, il est normal que les logiciels soient moins stables que les bâtiments

  1. Vrai

  2. Faux

Cycle de vie et cas d’utilisation¶

Terminologie¶

Processus de développement logiciel: Ensemble d'activités, de documents et des compétences nécessaires pour la réalisation d'un produit. Approche adaptée au contexte.

Cycle de vie: Vue de très haut niveau décrivant l'ordre dans lequel les disciplines sont effectuées.

Activités: Élément de travail. Décrit les tâches qui réalisent les artéfacts.

Artéfacts: Élément d’information. Généralement un document, mais peut être un courriel, ou même un échange verbal.

Rôle: Décrit les compétences requises pour faire une activité. Les responsables assignées à un rôle sont responsables des artéfacts produit par l’activité.

Cycles de vie: Cascade¶

Faisable si toutes les informations requises sont disponibles au début du projet.

Avantages:

  • Gestion facile
  • Toutes les tâches se planifient
  • Points de contrôle précis permettant de décider si l’on va de l’avant (go/no go)

Cycles de vie: Cascade¶

Cascade peut être approprié lorsque:

  • Faible incertitude au niveau des besoins du clients
  • Faible incertitude technique
  • Réalisation répétitive
  • Peu d’aspects novateurs
  • Faible participation du client/utilisateurs
  • Pas d’urgence de voir le produit fini

*** Un changement mineur peut avoir des répercussions à travers tout le projet.

Cycles de vie: Cascade (V, W ou X)¶

  • V : Activités de développement.

  • W, X : Ajout des activités d'assurance-qualité.

  • Approche essentiellement en cascade avec des revues et des inspections.

Cycles de vie: Incrémental (itératif/évolutif)¶

Itérations (cycles rapides) de production d’un produit fonctionnel. Les itérations sont indépendantes les unes des autres. Généralement, une itération dure entre 2 à 6 semaines. Une portion des exigences est connue au préalable.

Cycles de vie: Incrémental (itératif/évolutif)¶

Avantages

  • Génère du code fonctionnel rapidement dès le début du projet
  • Plus de flexibilité: plus facile de changer les exigences en cours de projet
  • Gestion du risque plus facile: une itération permet de passer à travers toutes les étapes du développement et d’identifier les problèmes.
  • Chaque itération est une petite approche cascade facile à gérer.

Désavantages

  • Des problèmes d’architecture peuvent survenir parce que les exigences ne sont pas toutes claires au départ.
  • Difficile de déterminer la fin du projet.
  • Difficile d’estimer adéquatement les tâches pour finir l’itération du temps.

Importance des exigences¶

À quoi servent les exigences?¶

  • Servent à définir le travail à faire : budget, échéancier, contrat avec les clients.

  • Servent de base a la conception: document d'architecture permettant la création du code.

  • Servent à définir les tests d'acceptation.

À quoi servent les exigences?¶

Document de vision¶

  • Une simple formulation du problème sur quelques pages. Problème décrit du point de vue des utilisateurs (décrit leurs besoins).

  • Besoin ≠ Exigence

    • Besoin est de haut niveau et flou Ex: Le système sera facile à utiliser.
    • Exigence est de plus bas niveau et plus formel
    • Ex: Chaque fonctionnalité du système doit avoir une info-bulle.

Les projets sont en retard à cause des exigences¶

  1. Requirements redinement
  2. Task dependencies
  3. Organizational alignment
  4. Organixational politics
  5. Geographic distribution

n.b.: "technical problems" ne fait meme pas parti du top 5

source: https://youtu.be/g3b8JfkV5jQ?feature=shared&t=334

Méthodes pour avoir les Exigence: Working Backwards (the Amazon Method) (addition par didier)¶

Idée¶

  • Partir d'une idée concrètes de ce que l'on veut à la fin

Sources¶

  • https://www.productplan.com/glossary/working-backward-amazon-method/
  • https://www.quora.com/What-is-Amazons-approach-to-product-development-and-product-management?ref=http://www.product-frameworks.com/

Méthodes pour avoir les Exigence: Building A Plane While Flying (addition par didier)¶

ide¶

  • construire le plus rapidement possible

  • Évite de construire des choses innnutile

  • Force d'avoir un produit rapidement

Sources¶

  • https://medium.com/@coachjennie/the-freedom-of-building-the-plane-while-flying-it-96dd2d899656

  • Pis 1 000 000 de résultats sur google

In [ ]:
https://neverworkintheory.org/

Markdown & Diagrams¶

Markdown - Historique¶

Définition¶

Markdown is a lightweight markup language for creating formatted text using a plain-text editor. John Gruber created Markdown in 2004 as a markup language that is easier to read in its source code form. Markdown is widely used for blogging and instant messaging, and also used elsewhere in online forums, collaborative software, documentation pages, and readme files.

-- wikipedia

Objectif du markdown¶

  1. Écrire de la documentation

  2. Façile à écrire

  3. Façile à lire directement

  4. Façile à convertir en HTML

Le markdown est utilisé partout!¶

  • github (gitlab) présente les fichiers avec une extension .md comme markdown

  • slack

  • Intégration avec tous les IDE

  • Jira

  • jupyter (ces notes de cours)

  • hugo (mon blogue)

  • https://gist.github.com/

  • https://obsidian.md/

GitHub Flavored Markdown¶

  • La version du markdown que nous utilisons usuellement

  • Extension de markdown pour ajouter des fonctionnalités non présentes dans la première version

  • Retrait de fonctionnalités insécures

Tous vos répo github devraient avoir un README.md¶

  • Écrit en markdown

  • Qui explique le projet

Où pratiquer sont markdown¶

Utilisons gist!¶

Recette¶

  1. logger-in dans github

  2. aller sur https://gist.github.com/

  3. Choisir un nom de fichier qui fini par .md

  4. cliquer sur "Preview" pour pré visualiser votre résultat

Markdown¶

Markdown (titres)¶

# Gros title 

Lorem ipsum dolor sit amet, consectetur adipiscing elit

## Title 

sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation

### Petit title
Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

HTML¶

Gros title¶

Lorem ipsum dolor sit amet, consectetur adipiscing elit

Title¶

sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation

Petit title¶

Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Markdown (liste non ordonnée)¶

* oignons

* carottes

* tomattes

HTML¶

  • oignons

  • carottes

  • tomattes

Markdown (liste numéroté)¶

1. oignons

2. carottes

3. tomattes

HTML¶

  1. oignons

  2. carottes

  3. tomattes

Markdown (tableaux)¶

https://www.tablesgenerator.com/markdown_tables

| Tables   |      Are      | Cool |
|:---------|:-------------:|-----:|
| col 1 is |  left-aligned | 1600 |
| col 2 is |    centered   |   12 |
| col 3 is | right-aligned |    1 |

HTML¶

Tables Are Cool
col 1 is left-aligned 1600
col 2 is centered 12
col 3 is right-aligned 1

Markdown (Équations pour walid)¶

Ceci est une equation inline: $e^{i\pi} + 1 = 0$

Ceci est une equation  $$\sin^2{x} + \cos^2{x} =  1$$

HTML¶

Ceci est une equation inline: $e^{i\pi} + 1 = 0$

Ceci est une equation $$\sin^2{x} + \cos^2{x} = 1$$

Markdown (code block)¶

Ceci est un code block

```python
def append(lst, x):
    return lambda ishead : x if ishead else lst
```

```js
function cons(lst,x){
    return function (isHead){
        return isHead ? x : lst; 
    }
}
```

HTML¶

Ceci est un code block

def append(lst, x):
    return lambda ishead : x if ishead else lst
function cons(lst,x){
    return function (isHead){
        return isHead ? x : lst; 
    }
}

Documentation¶

  • Cheatsheet: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet

  • github documentation: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github

  • Original post: https://daringfireball.net/projects/markdown/syntax

Mermaid¶

C'est quoi?¶

  • Un language pour faire beaux diagrams
  • Qui est rendu vraiment populaire comme extension avec le markdown
  • Facile à utiliser dans le html
---
title: Example Git diagram
---
sequenceDiagram
    Alice->>John: Hello John, how are you?
    John-->>Alice: Great!
    Alice-)John: See you later!

La manière de travailler avec mermaid¶

  1. prendre un exemple pas trop loin de ce que nous voulons https://mermaid.js.org/syntax/flowchart.html

  2. modifier l'exemple dans l'éditeur https://mermaid.live/edit

Documentation:¶

  • https://mermaid.js.org/intro/getting-started.html

  • https://mermaid.live/edit

Diagrammes UML¶

L'UML est le langage de modélisation standard le plus utilisé. Il définit 13/14 modèles (vues) différents basés sur une apparence (look-and-feel) similaire.

Diagramme de cas d’utilisation (use case diagram): Permet de modéliser les actions/fonctionnalités faites par un acteur (utilisateur) avec un futur logiciel.

Diagramme de séquence: Diagramme d'interaction qui met l'accent sur la chronologie de l'envoi des messages. Normalement, chaque cas d'utilisation détaillé a un diagramme de séquence. Le diagramme de séquence aide a faire le lien entre le cas d'utilisation (haut niveau) et le diagramme de classe (bas niveau).

https://en.wikipedia.org/wiki/Unified_Modeling_Language

dsd

Nous, nous verrons deux type de diagrams¶

  • Use Case Diagrams

  • Sequence Diagrams

Use Case Diagram¶

Tout ce cours est un plagit flagrant d'un vidéo de 12 minutes¶

  • https://www.lucidchart.com/pages/uml-use-case-diagram

  • https://www.youtube.com/watch?v=4emxjxonNRI

C'est quoi un "use case"?¶

Un cas d'utilisation, bloc fonctionnel ou cas d'usage (« use-case » en anglais), définit en génie logiciel et en ingénierie des systèmes une manière d'utiliser un système qui a une valeur ou une utilité pour les acteurs impliqués

Le cas d'utilisation correspond à un ensemble d'actions réalisées par le système en interaction avec les acteurs en vue d'une finalité.

L'ensemble des cas d'utilisation permet ainsi de décrire les exigences fonctionnelles d'un système en adoptant le point de vue et le langage de l'utilisateur final.

-- wikipedia

Cas d’utilisation (use case)¶

Objectifs des cas d’utilisation:

  • Capturer le comportement désiré du système
  • Spécifier ce que le système fait (fonctions), mais pas comment il le fait.
  • Servir d’entente entre les développeurs, les utilisateurs et les experts sur les fonctions disponibles et sur la façon d’interagir avec le système.
  • Servir à valider l’architecture logicielle qui sera développée.

Un cas d’utilisation est un document narratif qui décrit la séquence d’évènements dans laquelle un acteur (un agent externe) utilise un système pour accomplir un processus.

Cas d’utilisation (use case)¶

Les cas d’utilisation peuvent être spécifiés avec différents niveaux de détail:

  • Format de haut niveau

    • Abrégé, peu détaillé
    • Décrit le scénario principal seulement
  • Format informel

    • Court
    • Brève description des scénarios alternatifs
  • Format étendu:

    • Très détaillé
    • Description complète du scénario principal et des scénarios alternatifs

Cas d’utilisation de haut niveau¶

Un exemple de cas d’utilisation pour le guichet automatique:

Use case Effectuer un retrait
Acteur(s) Client
Type Primaire
Description Un client se présente au guichet automatique, s'identifie, retire un montant d'argent et quitte avec son argent

Use Case Diagram¶

  • Objectif: montré plusieurs "use case" sur le même diagram

  • Montrer comment le système interagit avec des "agents exterieurs"

  • Montrer les actions importantes

  • Montrer les relations entre les actions

  • Montrer les relations entre les acteurs et les actions

Briques¶

Use case diagram¶

dd

Diagramme de cas d’utilisation (use case)¶

  1. Après avoir identifié les requis du système, définir les frontières du système, puis identifier les acteurs et les cas d’utilisation.

  2. Écrire tous les cas d’utilisation en format de haut niveau et les catégoriser comme primaires, secondaires ou optionnels.

  3. Tracer un diagramme de cas d’utilisation (cas d’utilisation primaires).

  4. Identifier et illustrer les relations entre les cas.

  5. Écrire les cas d’utilisation les plus critiques, influents ou risqués dans un format étendu et essentiel.

  6. Écrire le minimum de cas réels.

  7. Ordonner les cas d’utilisation en ordre d’importance.

Diagramme de cas d’utilisation¶

Facile à comprendre par les utilisateurs et les développeurs.

Permet de faire un inventaire de haut niveau des exigences. Aide à détecter des exigences implicites ou oubliées.

Ce diagramme regroupe plusieurs cas d'utilisation (use cases) afin de donner une vue d'ensemble actions possibles.

Exemple pour faire un dessert...¶

  1. Faire dessert
    1. Faire Gateau
    2. Faire Glassage
  • Didier fait le gateau

  • Stephanie est la comme experte

À la base¶

Acteurs:

  • cuisinier médiocre

Systemes:

  • Cuisine

Actions

  • Faire Gateau
  • Faire dessert
  • faire glaçage

acteurs¶

  • Représente une "catégorie de personne" pas une personne

  • Peut être une personne physique, un système ou autre..

  • Les acteurs sont toujours extérieur au système

Acteurs principaux¶

  1. Initie l'intéraction avec le système
  2. Placé à gauche du diagram

Acteurs secondaires¶

  1. est réactif au système
  2. Placé à droite du diagram

Interations¶

Interations Acteurs-Actions:

  • Le cuisinier médiocre fait le dessert

Systemes:

  • Cuisine

Interations Acteurs-Actions:

  • Pour Faire Dessert il faut Faire Gateau
  • Pour Faire Dessert il faut Faire Glacage

Ajout d'autres acteurs¶

À la base¶

Acteurs:

  • cuisinier médiocre (principal)
  • cuisiniere supreme (secondair)

Systemes:

  • Cuisine

Actions

  • Faire Gateau
  • Faire dessert
  • faire glaçage
  • demander aide

Interations¶

Interations Acteurs-Actions:

  • Le cuisinier médiocre fait le dessert (principal)
  • La cuisiniere supreme donne de l'aide (secondair)

Systemes:

  • Cuisine

Interations Acteurs-Actions:

  • Pour Faire Dessert il faut Faire Gateau
  • Pour Faire Dessert il faut Faire Glacage
  • Faire Gateau peut utiliser Demander aide
  • Faire Glacage peut utiliser Demander aide

Exercices¶

À partir des exigences suivantes, faites-en un diagramme de cas d’utilisation.

  • Le jeu doit permettre au joueur de créer une partie
  • Le joueur qui crée une partie s'y join automatiquement
  • Le joueur peut quitter la partie à laquelle il joue
  • Chaque joueur peut avoir une liste d'amis conservée par le jeu
  • Un joueur peut ajouter un ami de la liste d'amis
  • Un joueur peut enlever un ami de la liste d'amis
  • Le jeur doit permetter au joueur d'inviter des amis faisant partie de sa liste d'ami à participer à une partie à laquelle il joue

Sequence diagram¶

Tout ce cours est un plagit flagrant d'un vidéo de 9 minutes¶

  • https://youtu.be/pCK6prSq8aw?feature=shared

Exemple¶

s

C'est quoi un sequence diagram¶

Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurs et le système selon un ordre chronologique

Le diagramme de séquence permet de montrer les interactions d'objets dans le cadre d'un scénario d'un diagramme des cas d'utilisation

La dimension verticale du diagramme représente le temps, permettant de visualiser l'enchaînement des actions dans le temps, et de spécifier la naissance et la mort d'objets.

Différentes parties d'un diagram en séquence¶

Flèches d'un diagram en séquence¶

Mermaid JS¶

  • Mermaid est excellent pour les séquence diagrams

https://mermaid.js.org/syntax/sequenceDiagram.html

Agilité - expérience personel¶

Notes importante¶

  • Tout ce qui suit est anecdotique
  • Il s'agit de mon expérience personelle
  • Désolé

Oubliez ça, j'ai des sources (ok, une)!¶

  • https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf

  • https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-French.pdf

  • https://agilemanifesto.org/iso/fr/manifesto.html

  • https://agilemanifesto.org/iso/fr/principles.html

  • https://www.agilealliance.org/glossary/backlog-refinement/

À quoi ressemble une compagnie?¶

Nombre de personnes¶

  • Entre 100 et 300 personnes

  • Surtout Business-to-business (B2B) vs Business-to-consumer (B2C)

  • Compagnie plus ou moins distribué

  • Environ 50% de la compagnie en "tech"

  • En 50% de la tech des programmeurs

Exemples¶

  • YouGov, firme de sondage

  • Behavox, logiciels pour banques

  • SquarePoint Capital, hedge found

  • Ivado Labs, consultation data science

Compagnie typique¶

flowchart TD
    C[Executif] --> T[Tech]
    C --> V[Vente]
    C --> F[Finance]
    C --> CS[Customer success]

Division de la tech¶

flowchart TD
    T[Tech] --> P1[Produit 1]
    T[Tech] --> P2[Produit 2]
    T[Tech] --> P3[Produit 3]
    T[Tech] --> Infra[Infrastructure]

Pression sur la tech¶

flowchart TD
    C[Executif] --> T[Tech]
    C --> V[Vente]
    C --> F[Finance]
    C --> CS[Customer success]
    V -.-> T
    CS -.-> T
    C -.-> T
    T -.-> T

Qui veut quoi?¶

Ventes¶

  • De nouvelles fonctionnalités pour les nouveaux clients
  • De nouvelles fonctionnalités pour des clients potentiels

Customer success¶

  • Réparer les bugs pour les clients existent
  • être certain que tout fonctionne tout le temps
  • Nouvelles fonctionnalités pour clients existant

Executif¶

  • Changer la direction de la compagnie

Tech¶

  • Réparer les bugs
  • Faire la maintenance
  • Payer la debt technique

Comme dirait un marxiste¶

Il y a des contracdictions dans le système

-- un marxiste random

Scrum team¶

Équipe scrum¶

L’unité fondamentale de Scrum est une petite équipe, la Scrum Team. La Scrum Team se compose d'un

Scrum Master, d'un Product Owner et de Developers. Il n’y a pas d’équipe dans l’équipe ni de hiérarchies. Il s'agit d’une seule et même unité stable, composée de professionnels focalisés sur un seul objectif à la fois, l'Objectif de Produit.

-- https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-French.pdf

Équipe scrum par mon expérience¶

  1. Équipe pluridisciplinaire (front-end developper, back-end, qa, data scientist)

  2. Équipe autonomne

  3. Petite, jamais en plus de 12 personnes

  4. Équipe qui à une seule mission (e.g.: gérer mio)

Personnes dans un scrum team¶

  • Developers

Les Developers sont les membres de la Scrum Team qui s'engagent à traiter tout ou partie utile d’un Increment à chaque Sprint.

  • Product Owner

Le Product Owner est redevable de maximiser la valeur du produit résultant du travail de la Scrum Team.

  • Scrum Master

Le Scrum Master est redevable de la mise en place de Scrum tel que défini dans le Guide Scrum.

Valeurs Scrum¶

  • Engagement
  • focus
  • ouverture
  • respect
  • courage

Événement Scrum Principal: Le Sprint¶

Sprint¶

  • Tout le travail se fait dans un "sprint"

  • L'équipe doit avoir un objectif prédéfinit

  • L'équipe doit compléter son travail

  • Block de temps de 2 semaines où le travail est prédéfini

  • Chaque tâche est définit dans un ticket ou jira

Sprint...¶

Durant le Sprint :

  • Aucun changement n’est permis, qui pourrait remettre en cause l’Objectif de Sprint ;
  • Les objectifs de qualité ne sont jamais revus à la baisse ;
  • Le Product Backlog est affiné si nécessaire ; et
  • Le périmètre peut être clarifié et renégocié avec le Product Owner selon ce qu'on en apprend.

-- scrum guide

En pratique..¶

  1. Un spring est une collection de tickets (jiras) qu'il faut faire
  2. Chaque ticket à une difficulté (en point)
  3. Le nombre total de points de l'équipe est la capacité de l'équipe

En pratiques¶

ss

Idée sous-jacente¶

  1. Le sprint à un objectif unique et très claire

  2. Tous les tickets sont nécessaire pour accomplire l'objectif

  3. Aucun tickets est innutile à l'objectif

  4. Les tickets sont tous ordonnées par priorité

  5. Les tickets n'ont aucune inter-dépendences

sprint tickets¶

Objectif: Faire site web de vote

Priority Title Point
1 Faire un site web grossier avec deno 3
2 Faire le front-end qui permet de voter 2
3 Permettre à différent utilisateurs de ce logger 2
4 Persister le les votes sur le backend 2
5 deployer en production 3
6 Ajouter une page d'analyse de resultat secrete 3
7 Créer un login pour admin 2

Comment les taches entres et sortes du sprint?¶

Product Backlog¶

Le Product Backlog est une liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit.

C'est l’unique source du travail entrepris par la Scrum Team.

-- scrum guide

Product Backlog¶

  1. Le product owner est rempli de "user stories" à faire

  2. Les taches ne devrait pas être technique

Product Owner¶

Le product owner est responsable de parler aux autres équipes (tech ou autres) prendre des requis.

  • Le product owner est responsable du product backlog

  • Il se promène d'équipe en équipe pour prendres les requis

Meeting: Sprint Planning¶

  1. Le product owner arrive avec les choses qui doivent être faites

  2. Les développeur brisent les "user stories" en tickets techniques

  3. Il y a une discussion entre le product owner et la sous équipe technique sur quoi faire (priorité vs facilité)

Daily Scrum¶

À chaque jour, toute personne se rencontre pour dire¶

  1. sur quoi il travail
  2. ça va bien ou pas

Objectif: avoir une transparence totale sur l'état du sprint.

À la fin du Sprint¶

Sprint Review¶

  • On assit les clients de l'équipe et on leurs montre ce qui a été fait durant le sprint.
  • On prend les feedbacks calmement
  • On ouvre de nouvelles user stories

Sprint rétrospection¶

  • On lave notre linge sale en famille

  • On sépare ce qui à fonctionné de ce qui à mal été de ce qui à très mal été

  • On prépare des actions concrètes pour s'améliorer

In [ ]:
 

Principe solide¶

C'est quoi SOLID¶

En programmation orientée objet, SOLID est un acronyme mnémonique qui regroupe cinq principes de conception destinés à produire des architectures logicielles plus compréhensibles, flexibles et maintenables. Les principes sont un sous-ensemble de nombreux principes promus par l'ingénieur logiciel et instructeur américain Robert C. Martin.

-- wikipedia

  • C'est un accronyme qui représente 5 conceptes

  • Très axé sur la programmation objet

  • C'est un moyen de savoir si du code est bon

Mais, ça veut dire quoi?¶

  • Responsabilité unique (Single responsibility principle)

  • Ouvert/fermé (Open/closed principle)

  • Substitution de Liskov (Liskov substitution principle)

  • Ségrégation des interfaces (Interface segregation principle)

  • Inversion des dépendances (Dependency inversion principle)

Responsabilité unique¶

une classe ne doit changer que pour une seule raison

There should never be more than one reason for a class to change."[5] In other words, every class should have only one responsibility.

-- Robert C. Martin (Uncle bob)

Conséquences¶

  • Une class doit être petite

  • Un objet doit être immutable sauf, au maximum à une seule place

Regardons ce mauvais exemple...¶

Ouvert/fermé¶

Principe Ouvert/fermé¶

une entité applicative (classe, fonction, module ...) doit être fermée à la modification directe mais ouverte à l'extension

Software entities ... should be open for extension, but closed for modification.

-- Robert C. Martin (Uncle bob)

Conséquence¶

  1. Le plus qu'une classe est utilisé, le plus difficile c'est d'en hériter

  2. Il ne faut jamais changer les arguments d'une méthode hérité

  3. Il faudrait toujours appeler la méthode parente

  4. Une classe qui a des enfants ne peut changer façilement

Regardons ce mauvais exemple...¶

Principe de substitution de Liskov¶

Substitution de Liskov¶

une instance de type T doit pouvoir être remplacée par une instance de type G, tel que G sous-type de T, sans que cela ne modifie la cohérence du programme

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it

-- Robert C. Martin (Uncle bob)

En français¶

Une sous-classe doit être capable d'être utilisé aux même places que la classe parente

Conséquences¶

  1. Le plus qu'une classe est utilisé, le plus difficile c'est d'en hériter

  2. Le plus qu'une classe à d'enfants, le plus difficile il est de changer la classe

Ségrégation des interfaces¶

préférer plusieurs interfaces spécifiques pour chaque client plutôt qu'une seule interface générale

Clients should not be forced to depend upon interfaces that they do not use.

-- Robert C. Martin (Uncle bob)

Go proverbs¶

interface{} says nothing.

The bigger the interface, the weaker the abstraction.

-- rob pike

https://go-proverbs.github.io/

Rich Hickey¶

https://www.youtube.com/watch?v=aSEQfqNYNAc

La banane¶

I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

-- Joe Armstrong

Conséquence¶

  • Une interface devrait être le plus petit possible

  • En python, les

Inversion des dépendances¶

il faut dépendre des abstractions, pas des implémentations

-- Robert C. Martin (Uncle bob)

Principe d'inversion des dépendances¶

Les deux assertions de ce principe sont :

  1. Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d'abstractions.

  2. Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.

Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d'abstractions.¶

Analogie¶
  • Ma balayeuse ne dépend pas de l'"électricité", elle dépend de la prise électrique.

    • balayeuse: haut niveau
    • électricité: bas nieveau
    • prise électrique: interface

Dépendence directe¶


flowchart TD
    T[Base de donne] --> P1[Load User]

Dépendence avec interface directe¶

flowchart TD
    T[Base de donne]-- implemente -->I[User Repository Interface] 
    P1[Load User]-- utilise -->I

Pour les testes..¶

  1. Ajoutons une implementation "in memory"
flowchart TD
    T[Base de donne]-- implemente -->I[User Repository Interface] 
    F[In memory db]-- implemente -->I
    P1[Load User]-- utilise -->I

La production peut utiliser la base de donnée¶

flowchart TD
    Controller --> P[+]
    T[Base de donne] --> P
    P1[Load User] --> P

Les testes peuvent utiliser la base de donnée "in memory"¶

flowchart TD
    Test --> P[+]
    T[In memory db] --> P
    P1[Load User] --> P

Les testes¶

C'est quoi un tests?¶

C'est quoi un test?¶

C'est du code qui vérifie du code.

-- didier

C'est quoi un test?¶

En informatique, un test désigne une procédure de vérification partielle d'un système. Son objectif principal est d'identifier un nombre maximal de comportements problématiques du logiciel. Il permet ainsi, dès lors que les problèmes identifiés seront corrigés, d'en augmenter la qualité.

-- wikipedia

Pyramide de tests¶

Tous les tests ne sont pas égaux¶

  • Le plus de choses un test vérifie, le moins le test veut dire quelque chose

  • Le plus de choses un test vérifie, le plus façile il est à écrire

Monsieur le garagiste, je n'ai pas réussit à aller à l'épicerie avec ma voiture aujourd'hui. Je pense qu'elle est brisé. Pouvez-vous la réparer, si oui, quand sera-t-elle réparée ?

-- didier, la première fois qu'il ira au garagiste

Les différents niveaux de tests¶

Test d'acceptation (Acceptance testing)¶

En informatique, le test d'acceptation (ou recette) est une phase de développement des projets, visant à assurer formellement que le produit est conforme aux spécifications (réponse donnée à un instant « t » aux attentes formulées). Elle s'inscrit dans les activités plus générales de qualification.

  • Executé juste avant de déployer en production

  • Test plusieurs systèmes

  • Test très vaste

  • D'habitude fait par les QAs

Tests système (System testing)¶

Les tests système de logiciel ou de matériel réfèrent à un processus de test d'un système intégré afin d'évaluer sa conformité aux exigences spécifiées.

  • Test 1 système de bout-en-bout

  • Même chose qu'un système d'acceptation mais sur 1 système

  • D'habitude fait par les QAs

Test d'intégration (Integration testing)¶

Vérifie le bon fonctionnement d'une partie précise d'un logiciel ou d'une portion d'un programme (appelée « unité » ou « module ») ; dans le test d’intégration, chacun des modules indépendants du logiciel est assemblé et testé dans l’ensemble.

  • Test une partie d'un système
  • Test avec des "gros" mocks, (aka une base de donnée faite que pour cela)
  • Fait par les développeurs

Test de composants (unit testing)¶

En programmation informatique, le test unitaire est une procédure permettant de vérifier le bon fonctionnement d'une partie précise d'un logiciel ou d'une portion d'un programme (appelée « unité » ou « module »).

  • Test une seule fonction sans dépendences sur autre services
  • Fait par les développeurs
  • Les dieux du test

Comment écire des tests?¶

Exercice¶

Écrire un test de la fonction suivante

def is_balanced(text: str) -> bool:
    counter = 0
    for letter in text:
        if letter == "(":
            counter += 1
        if letter == ")":
            counter -= 1
        if counter < 0:
            return False
    return counter == 0

Réponse¶

def test_is_balances():
    assert is_balanced("")
    assert is_balanced("()")
    assert is_balanced("(()())")
    assert not is_balanced("((())")
    assert not is_balanced("(()))")
    assert not is_balanced(")")

Exercice¶

Écrire un test de la fonction suivante

def is_balanced_file(file_path: Path) -> bool:
    with open(file_path, "r") as file_:
        text = file_.read()
        counter = 0
        for letter in text:
            if letter == "(":
                counter += 1
            if letter == ")":
                counter -= 1
            if counter < 0:
                return False
        return counter == 0

Note sur la réponse¶

  • La méthode est façile à tester car elle fait une seule chose! Il s'agit du S dans Solid

Réponse, option 1¶

def write_to_tmp_file(tmp_dir: Path, content: str) -> Path:
    tmp_file = tmp_dir / "foo.txt"
    tmp_file.write_text(content)
    return tmp_dir


def test_is_balanced_file(tmp_path):
    tmp_path = Path(tmp_path)
    assert is_balanced_file(write_to_tmp_file(tmp_path, ""))
    assert is_balanced_file(write_to_tmp_file(tmp_path, "()"))
    assert is_balanced_file(write_to_tmp_file(tmp_path, "(()())"))
    assert not is_balanced_file(write_to_tmp_file(tmp_path, "((())"))
    assert not is_balanced_file(write_to_tmp_file(tmp_path, "(()))"))
    assert not is_balanced_file(write_to_tmp_file(tmp_path, ")"))

Note sur la réponse 1¶

  • Ceci est un test d'intégration

  • Le test dépend de fichiers

    • Ça semble peu, mais ça peut être problématique

Réponse, option 2, partie 1¶

premièrement, on change la fonction

def is_balanced_file_object(file_path: typing.IO[str]) -> bool:
    text = file_path.read()
    counter = 0
    for letter in text:
        if letter == "(":
            counter += 1
        if letter == ")":
            counter -= 1
        if counter < 0:
            return False
    return counter == 0

Réponse, option 2, partie 2¶

On test avec une version inmemory

def test_is_balanced_file_object() -> None:
    assert is_balanced_file_object(io.StringIO(""))
    assert is_balanced_file_object(io.StringIO("()"))
    assert is_balanced_file_object(io.StringIO("(()())"))
    assert not is_balanced_file_object(io.StringIO("((())"))
    assert not is_balanced_file_object(io.StringIO("(()))"))
    assert not is_balanced_file_object(io.StringIO(")"))

Note sur la réponse 2¶

  • Pour rendre la méthode façile à tester, il faut utiliser la notion d'Inversion des dépendances de SOLID

Réponse, option 3¶

On change la fonction is_balanced_file pour utiliser la fonction is_balanced On ne test pas la méthode is_balanced_file

def is_balanced_file(file_path: Path) -> bool:
    with open(file_path, "r") as file_:
        return is_balanced(file_.read())

Note sur la réponse option 3¶

  • Le code coverage du résultat sera plus bas

  • Est-ce vraiment grave? didier pense que non

Exercice¶

  • Écrire une fonction qui prend en argument une liste d'entiers lst et un entier target. La fonction doit retourner 2 nombres de la lst (possiblement deux fois le même nombre) a et b tel que a + b = target.

  • Tester la fonction

https://leetcode.com/problems/two-sum/

Exemple¶

lst = [55, 20, 76, 34, 80, 26]
target = 100
result = (20, 80)

Exercice¶

  • Écrire une fonction qui prend un string en paramêtre et qui retourne le plus long "sous-string" qui est un palindrome

  • Tester la fonction

https://leetcode.com/problems/longest-palindromic-substring/

Exemple¶

input_ = "la plus belle ville au monde est laval."
result = "laval"

Petit (moyer, ok gros.. ) exercice¶

En utilisant le module random de python, écrire une fonction qui retoure un mouvement brownien de longeur $n$ et tester le.

Un mouvement brownien est une liste de nombre où le premier item est $0$ et l'item $n+1$ est définit comme la valeur de l'item $n$ plus une valeur aléatoire provenant d'une normale de moyenne 0 et d'écart-type 1.

In [17]:
%pylab inline
from random import Random

def brownian_movement(n, random):
    ret = [1]
    for i in range(n - 1):
        ret.append(ret[-1] + random.gauss(0, 1))
    return ret

plot(list(range(250)), brownian_movement(250, Random(80)))
None
%pylab is deprecated, use %matplotlib inline and import the required libraries.
Populating the interactive namespace from numpy and matplotlib

Pytest: fixtures¶

Problème explicatif¶

  • Écrire une fonction qui prend le nom d'un fichier et qui compte le nombre de ligne dans le fichier

  • Écrire un teste

In [27]:
# Solution

def count_number_of_line(filename: str) -> int:
    with open(filename, "rt") as file_:
        return file_.read().count("\n")
    

Pour tester cela¶

  1. On va créer un fichier temporaire
  2. On va écrire un tests
  3. On va effacer le fichier temporaire

Ce qui se passe avant le test¶

  • Ce qui se passe avant un test se nomme souvant "setup", "beforeEach"

  • Si nous ne sommes pas capable de rouler le "setup", le test doit échouer

Ce qui se passe après le test¶

  • Ce qui se passe après le teste se nomme souvant "tearDown", "afterEach"

  • Il est important que ce qui se passe après le test soit toujours executé!

Pytest - fixtures¶

  • Pytest utilise un manière un peu particulière pour gérer les setup & teardown

  • Chaque setup et teardown est associé à une "chose": la fixture

  • Le code qui génère une fixture est un "setup"

  • Le code qui est roulé après une fixture est un "teardown" (avancé)

Utiliser des fixtures¶

  • Les arguments des fonctions tests sont des fixtures

  • Pytest inclue des fixtures https://docs.pytest.org/en/6.2.x/fixture.html

  • La fixture la plus utile est https://docs.pytest.org/en/6.2.x/reference.html#std-fixture-tmp_path

from pathlib import Path

def test_copy_file(tmp_path: Path) -> None:
    ...

Créer nos fixtures¶

import pytest

@pytest.fixture
def odd_number() ->:
    return 2 * 25231

def test_is_odd(odd_number) -> None:
    assert is_odd(odd_number)
    assert not is_odd(odd_number + 1)

Créer nos fixtures... suite¶

  • Les fixtures peuvent utiliser d'autres fixtures
import pytest

@pytest.fixture
def odd_number() -> number:
    return 2 * 25231

@pytest.fixture
def even_number(odd_number) -> number:
    return odd_number + 1

def test_is_odd(even_number) -> None:
    assert not is_odd(even_number)
    assert is_odd(even_number - 1)

Exercices - 1¶

  • Écrire un programme qui prend le nom d'un fichier JSON personnes et qui retourne le nombre d'homme dans le fichier.

  • Tester la fonction en utilisant des fixtures

exemple d'input

[
    {"name": "paulette", "sexe": "femme"},
    {"name": "claudette", "sexe": "homme"},
    {"name": "paul", "sexe": "homme"},
    {"name": "herménégilde", "sexe": "homme"},
]

Exercices - 2¶

  • Écrire un programme qui prend deux nom de fichiers et qui vérifie si les deux fichiers ont le même contenue

  • Tester la fonction en utilisant des fixtures

Exercices - 3¶

  • Écrire une fonction qui prend un Player et qui ajoute à un fichier une ligne avec la personne sérialisé en format {prenom} {nom de famille} - {équipe}

  • Tester la fonction en utilisant des fixtures

class Player:
    def __init__(self, first_name, last_name, team):
        self.first_name = fist_name
        self.last_name = last_name
        self.team = team


def serialize_player_to_file(player: Player, filename: Path) -> None:
    pass

Mocks¶

Des fois, nous ne sommes pas capable d'isoler nos functions¶

  1. La fonction ne fait que du input/output

  2. La fonction dépend de libraries merdiques

  3. Il serait compliquer de tout découpler

Exercices¶

  • Écrire une fonction qui prend en argument un url ainsi qu'un nom de fichier et qui télécharge l'url dans le fichier.

  • Tester la fonction

truc

  • utiliser l'url https://httpbin.org/get

  • utiliser la librarie requests

  • il n'y a pas de trucs ici, il faut faire du IO :(

Que pouvons nous faire dans cette situation là?¶

  1. Utilisé du IO mais très restraint (pas toujours possible)

  2. Mocker

Python mock¶

  • Python possède une des meilleur libraries pour faire des mocks

  • https://docs.python.org/3/library/unittest.mock.html

TDD¶

Écrire des tests est difficile¶

  • On a vue qu'écrire des tests est difficile.

  • Les fonctions doivent faire une et une unique chose

  • Les fonctions doivent utiliser la notion la notion d'Inversion des dépendances

Est-ce que nous pouvons nous faciliter la vie?¶

Oui! En écrivant les tests avant d'écrire le code.

Test Driven Development¶

  • Développé par Kent Beck

  • Provien du début des années 2000

  • Est un accronyme vraiment important à ajouter à votre CV

Les 3 phases du TDD¶

Les 3 phases du TDD¶

État initial¶

  1. Tous les tests passent

Développement¶

  1. Nous allons écrire un test unitaire qui ne passe pas
  2. Nous allons écrire le code minimal pour le faire passer
  3. Nous allons bouger des choses dans le code (refactoring)
  4. On recommence

État final¶

  1. Tous les tests passent

Pourquoi TDD¶

  1. Nous allons avoir un ensemble de test qui vérifie parfaitement le logiciel

  2. Le code sera testable dès le jour 1

  3. Le project sera toujour à 15 minutes d'être près pour la production

  4. Nous allons avoir des exemples de chanques fonction dans le code

  5. Nous allons utiliser très peu de mocks

  6. Les tests seront aussi beau que le code de base

Références¶

Bibliographie¶

  • https://youtu.be/k7_WBqd6C0Y

  • https://youtu.be/wMY5FE59rkI

  • https://tddmanifesto.com

Test-Driven Development¶

Le problème¶

Nous savons que¶

  1. Il faut écrire des testes

  2. Les programmeurs doivent écrirent des tests

    1. Tests unitaires

    2. Tests d'intégrations

Problème: comment ça devrait se passer en pratique?¶

  • Quand devons nous écrire des tests

  • Quelle devrait être la porté des tests

Solution: Test-Driven Development¶

  • Abbreviation: TDD

C'est quoi le Test-Driven Development (TDD)¶

Le Test-Driven Development¶

  • C'est une méthode d'écritude de programme

  • C'est pratiquement spirituel

  • Ça ne dépend pas de libraries où de paradigmes

Comment Écrire du code manière TDD?¶

Point de départ¶

On commence toujours par un projet où tous les tests fonctionnent.

Pourquoi?¶

  1. Il faut partir d'une base solide pour construire un édifice solide.

Étape 1¶

Écrire un test qui échoue. Un test qui ne "compile pas" est un test qui échoue.

Pourquoi¶

  1. Avant d'écrire du code, il être capable d'articuler ce que nous voulons obtenir. Comme les programmeurs parle en language de programmation, quoi de mieux qu'un test pour décrire ce que nous voulons

Vérification¶

On va rouler tous les tests et un seul test devait échouer

Pourquoi¶

  1. Mieux vaut avoir une ceinture et des bretelles

Étape 2¶

Écrire le code le plus simple qui fait en sorte que le test n'échoue plus.

Pourquoi¶

  1. Pour s'assurer de ne pas écrire du code non testé ou d'extra, il faut s'assurer d'écrire le minimum possible

Vérification¶

On va rouler tous les tests et plus un aucun tests ne devaient échouer

Pourquoi¶

  1. Mieux vaut avoir une ceinture et des bretelles

Étape 3¶

Réfactorer le code pour qu'il soit plus lisible, meilleur. Jusqu'à ce que vous soyez fier!

Pourquoi¶

  1. Sans ajouter de nouvelles fonctionnalitées, il faut devenir fier de son code.

Repeat¶

On boucle la boucle et on revient à l'étape 1.

Exemple - Kata¶

Écrire un programme qui...¶

Compte le pointage au bowling!

https://bowlinggenius.com/

  • https://kata-log.rocks/bowling-game-kata

Exercices - Kata¶

  • https://kata-log.rocks/christmas-lights-kata

  • https://kata-log.rocks/mars-rover-kata

  • https://kata-log.rocks/roman-numerals-kata (j'ai déjà eu cela en entrevue)

  • https://kata-log.rocks/tic-tac-toe-kata

Référence¶

  • https://www.youtube.com/watch?v=rBcV1F7jyHw

  • https://www.youtube.com/watch?v=BKgdrEPYqmM

Mocks¶

Des fois, nous ne sommes pas capable d'isoler nos functions¶

  1. La fonction ne fait que du input/output

  2. La fonction dépend de libraries merdiques

  3. Il serait compliquer de tout découpler

Exercices¶

  • Écrire une fonction qui prend en argument un url ainsi qu'un nom de fichier et qui télécharge l'url dans le fichier.

  • Tester la fonction

truc

  • utiliser l'url https://httpbin.org/get

  • utiliser la librarie requests

  • il n'y a pas de trucs ici, il faut faire du IO :(

In [8]:
import requests
from pathlib import Path
from shutil import copyfileobj

def download_to_file(url: str, dest: Path) -> None:
    with requests.get(url, stream=True) as resp:
        resp.raise_for_status()
        with open(dest, 'wb') as file_:
        copyfileobj(resp.raw, file_)


download_to_file("https://httpbin.org/get", Path("/") / "tmp" / "foo")
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Cell In[8], line 10
      6         resp.raise_for_status()
      7         print(resp.file)
---> 10 download_to_file("https://httpbin.org/get", Path("/") / "tmp" / "foo")

Cell In[8], line 7, in download_to_file(url, file_)
      5 with requests.get(url, stream=True) as resp:
      6     resp.raise_for_status()
----> 7     print(resp.file)

AttributeError: 'Response' object has no attribute 'file'

Que pouvons nous faire dans cette situation là?¶

  1. Utilisé du IO mais très restraint (pas toujours possible)

  2. Mocker

Python mock¶

  • Python possède une des meilleur libraries pour faire des mocks

  • https://docs.python.org/3/library/unittest.mock.html