Développement Logiciel / Bonnes pratiques Flashcards
1
Q
Selon clean code, quel est le principe d’un commentaire ?
A
Expliquer des choses que le code ne peut peut pas exprimer de lui même.
2
Q
Selon clean code, que faut t’il éviter dans un commentaire ?
A
Les données déjà save par git (date, auteur…), mal rédigés, le code mis en commentaire .
3
Q
Selon clean code, quelles sont les bonnes pratiques au niveau des arguments de fonction ?
A
Le moins possible, pas d’arguments de sortie, les arguments booléens
4
Q
Que faire avec un test qui ne passe pas ?
A
Ne pas le supprimer, mais plutôt le réparer.
5
Q
Que doit faire une fonction ?
A
Exactement ce qu’on attend d’elle, ne pas qu’elle ai un comportement caché, sinon on n’aura plus confiance dans le code.
6
Q
Qu’est ce que la redondance selon clean code ?
A
Le mal
7
Q
Fonction et abstraction selon clean code ?
A
Une fonction doit avec son propre niveau d’abstraction. Il ne faut pas mélanger bas niveau et haut niveau.
8
Q
Classe mère et classe fille selon clean code ?
A
La classe mère ne doit pas connaitre les classes filles.
9
Q
Que doit on faire avec le code mort ?
A
Le supprimer, de toute façon il est save avec Git.
10
Q
Qu’est ce que la séparation verticale (clean code) ?
A
Le code doit se rapprocher le plus possible au niveau vertical des méthodes qu’il appelle, pour ne pas devoir scroller pendant des heures.
11
Q
Quel est l’ordre des opérations en informatique ?
A
Dans le même ordre qu’en mathématique.
12
Q
Qu’est ce que l’incohérence dans Clean Code ?
A
Le fait de toujours faire une chose de la même manière dans le code, sauf à des endroits sans aucune justification
13
Q
Qu’est ce que le désordre dans Clean Code ?
A
Le fait de mal ranger ses fichiers et dossiers
14
Q
Qu’est ce que les variables explicatives ?
A
Le fait de stocker des résultats intermédiaires pour rendre plus lisible l’intention de l’algorithme
15
Q
Est-ce une bonne idée de faire un nom de fonction long ?
A
Oui, si on ne peut pas rendre clair le rôle de la fonction avec un nom court.
16
Q
Que faut t’il préférer au switch / if else ?
A
Le polymorphisme.
17
Q
Qu’est ce qu’un nombre magique ?
A
C’est un nombre qui n’a pas variable associée, qui est juste posée comme ça dans le code. C’est une erreur quand on veut comprendre le code, ou faire du refactoring.
18
Q
Qu’est ce que doivent faire une fonction ?
A
Une seule chose.
19
Q
Que faut t’il éviter avec les fonctions booléens ?
A
Pas de négatif, c’est à dire pas de “Not” dans le nom.
20
Q
Comment bien choisir un nom de fonction ?
A
Clair sur son rôle, et clair sur son niveau d’abstraction.
21
Q
Que faut t’il éviter au niveau de la codification des noms de variable ?
A
Le hungarian case par exemple, qui consiste à préciser le type de la variable : name_s, age_i.. C’est pas beau. Il faut aussi éviter le mot list, ou object dans le nom des variable. Pour list, mieux vaut préférer le s du pluriel.
22
Q
Qu’est il nécessaire lors des tests unitaire selon clean code ?
A
Qu’il teste assez de chose, qu’ils soient rapide à executer et qu’il y ai un outil de couverture de code.
23
Q
Est il possible d’atteindre des tests exhaustifs ?
A
Non
24
Q
Pourquoi il vaut mieux tester le plus tôt possible ?
A
Pour éviter les problèmes en prod, et donc perdre de l’argent
25
Comment sont placés les bugs ?
Ils sont souvent regroupés entre eux. Donc si il y a un problème quelque part, c’est bien de chercher d’autres bugs autour aussi
26
Si le produit est mal conçu, à quoi sert de corriger les bugs ?
A rien, puisque les specs sont mauvaises
27
Que faut il faire au niveau des tests avec les fonctionnalités critiques ?
Rajouter beaucoup de tests unitaires
28
Ou mène le mauvais code ?
Vers la faillite : réduit la productivité, l’ajout de features, la maintenance et le turnover
29
Est ce que la remise à Zero (refaire app) est une bonne chose ?
ça peut l’être si le code est vraiment dégeux. Par contre, si y’a pas de bonnes pratiques, alors on repart pour du code degeux.
30
Comment lutter contre la pression du patron qui veut accélèrer, quitte à faire du code dégeux ?
C’est dans son intérêt, métaphore avec le batiment (fondations sont pourries), et on est les seuls à connaître le code, il faut le protéger.
31
Selon Clean code, que sont les développeurs ?
Des artistes.
32
Qu’est ce qu’un code propre ?
Fait pour être lu, élégant, simple et direct, pas redondant et compris par les autres, avec des niveaux d’abstractions.
33
Quelles sont les règles de Dijkstra dans le clean code ?
Un seul return, pas de break ou de continue, jamais de goto
34
Comment rendre les constructeurs plus clairs ?
On peut faire des constructeurs statiques, pour ajouter un nom au constructeur.
35
Comment faire une bonne séparation verticale ?
Doit être lu comme un journal, le titre en haut, les notions clés ensuite, puis les détails. On assemble les mêmes idées entre elles.
36
Comment faire une bonne mise en forme horizontale ?
Mettre un espace entre les opérations, limite de longueur, ne pas rompre l’identation
37
Quel est le principe du singleton ?
Une seule instance d’une classe dans tout le code
38
Comment mettre en place un singleton ?
Une classe, avec un constructeur private et une méthode statique qui voit instancier ou retourner notre singleton
39
Quand mettre en place le singleton ?
1 : On veut un seul et unique object, avec les mêmes paramètres, pour tous les utilisateurs. 2 : On veut accéder facilement à l’object, sans le passer via des paramètres ou des variables globales.
40
Quels sont les avantages du singleton ?
On garantie l’unicité de l’instance, Point d’accès global, sans variables globales
41
Quels sont les inconvénients du singleton ?
Ne respecte pas SOLID, convient mal avec le multithreading, les tests unitaires deviennent compliqués.
42
Quel est le principe de la Fabrique (Factory) ?
Remplace les appels directs des constructeurs des objets par une classe qui gère la logique de construction.
43
Comment mettre en place une Factory ?
Créer une classe Factory, avec la logique de construction dedans. Supprimer les appels directs des constructeurs d’objets.
44
Quand mettre en place la Factory ?
Quand on a trop de logique dans les constructeurs, ou dans le choix des objets à instancier. Sert à éviter les gros if else / switch case, et d’isoler la logique de construction.
45
Quels sont les avantages de la Factory ?
Responsabilité unique : déporter la logique de construction. Ouvert/fermé : Permet de construire de nouveaux objets facilement.
46
Quel est le principe de l’Abstract Factory ?
Une factory, mais avec des classes filles Factory, tout simplement.
47
Quel est le principe du Builder Pattern ?
On ajoute des classes intermédiaires, qui vont nous servir pour définir les valeurs des attributs / valeurs du constructeurs. Pour une classe Computer, on va donc définir un GamingComputerBuilder, un DeskComputerBuilder, un LaptopComputerBuilder… Tout en construisant toujours un object de type Computer
48
Quand utiliser le Builder Pattern ?
1. Quand on a beaucoup d’arguments dans un constructeur. 2. Quand on a beaucoup de variations dans les paramètres du constructeur, mais peu de variation dans la logique des objets (sinon on ferait directement des classes filles)
49
Quels sont les avantages du Builder Pattern ?
On évite les créations d’objet via le constructeur qui ne veulent rien dire. On découpe le code de construction du métier. On peut réutiliser le même code de construction pour d’autres objets.
50
Quels sont les inconvénients du Builder Pattern ?
Nécessite beaucoup de classes. Si il y a de la logique métier pour les différents objets construits par le Builder, autant faire des classes filles avec une Factory.
51
Quel est le principe du Prototype ?
On définit une méthode clone pour les objets, pour copier un objet sans avoir besoin d’appeler un constructeur.
52
Quand utiliser le Prototype ?
Quand les objets sont une galère à créer (constructeurs d’une lib qui prend trop de paramètres, ou trop flou)
53
Quels sont les avantages du Prototype ?
Cloner des objets sans faire toutes l’initialisation, et donc retirer du code redondant, Créer des objets complexes facilement en copiant
54
Quels sont les inconvénients du Prototype ?
Les relations entre objets, surtout circulaires, deviennent presque impossible à gérer (il faut cloner, puis cloner, mais recloner après ?)
55
Quel est le principe de l’Adaptateur ?
On va adapter une classe à une interface, sans modifier la classe.
56
Comment mettre en place l’Adaptateur ?
Imaginons une classe d’une librairie. Elle n’implémente pas une interface souhaitée. On va venir l’enrober (ou faire une classe fille), qui va implémenter les fonctions de l’interface souhaitée.
57
Quand utiliser l’Adaptateur ?
Quand on ne peut pas modifier une classe, mais qu’on veut implémenter une interface dedans
58
Quel est le principe du Pont ?
On découpe notre objets en petits objets implémentant une interface. ça permet d’être beaucoup plus flexible dans l’utilisation de notre objet.
59
Comment mettre en place le Pont ?
Diviser les responsabilités d’une classe, les découper en sous-classes. Implémenter une interface pour ces sous-classes. Donner la possibilité, par exemple dans le constructeur, de pouvoir choisir l’objet à utiliser. (exemple, donner un objet pour choisir le display)
60
Quand utiliser le Pont ?
1. Quand on souhaiter diviser une classe trop monolithique. 2. Si on veut avoir une logique abstraite, non dépendante du type d’objet
61
Quel est le principe du Composite ?
Quand on a une structure en arborescence, implémenter une même interface, autant pour les branches que pour les feuilles.
62
Quand utiliser le Composite ?
Quand on a une structure en arborescence, et qu’on veut la parcourir, sans checker à chaque fois le type d’objet.
63
Quel est l’inconvénient de Composite ?
Il peut être compliqué de trouver des interfaces communes, ou alors on les rend trop génériques, les rendant impossible à comprendre.
64
Quel est le principe du Décorateur ?
On va enrober une propriété, une méthode, un constructeur… d’un comportement, avant ou après.
65
Quand utiliser le Décorateur ?
On veut étendre des comportements seulement au moment de l’exécution, sans alterer le code source des objets. (donc par exemple un décorateur d’un framework), ou si l’héritage est impossible ou n’a pas de sens.
66
Quels sont les avantages du Décorateur ?
Etendre le comportement de l’objet sans avoir besoin de créer une nouvelle sous-classe, ajouter ou retirer dynamiquement des responsabilités à un objet au moment de l’exécution, combiner plusieurs comportements en emballant plusieurs décorateurs…
67
Quels sont les inconvénients du Décorateur ?
Retirer un décorateur n’est pas facile, pas facile de mettre un décorateur qui ne dépend pas de sa position, code de configuration des couches de décorateur peut être moche.
68
Quel est le principe d’une Facade ?
Cacher le code complexe pour offrir un point d’accès simple à une feature. On utilise souvent une classe statique pour ça. La façade doit gérer tout le cycle de vie des sous systèmes…
69
Quand utiliser une Facade ?
Quand on veut simplifier l’utilisation d’une API. Quand on a besoin d’une sous partie d’une API complexe. Quand on veut structurer un sous systèmes en plusieurs couches.
70
Quel est l’avantage d’une Facade ?
On simplifie un sous-sytème complexe.
71
Quels sont les inconvénients d’une Facade ?
Peut devenir un objet omniscient. Si c’est le cas, il faut diviser en sous Facades.
72
Quel est le principe du Proxy ?
On ajoute une couche autour d’un service, ce qui va nous permettre d’ajouter un comportement. Service de log, de cache, d’authentification… C’est un peu un middleware.
73
Quand utiliser le Proxy ?
Authentification, logs, lancement d’un service distant, mise en cache, gestion d’erreur…
74
Quels sont les avantages du Proxy ?
Controller le service sans toucher au code source, gérer le cycle de vie du service…
75
Quel est le principe du poids mouche ?
On va faire partager des données communes aux objets, pour éviter la redondance et donc la RAM.
76
Quand utiliser le poids mouche ?
Quand un programme génère trop d’objets, donc consomme trop de ressources (exemple avec des balles). Quand les objets contiennent des états identiques qui peuvent être partagés.
77
Quels sont les avantages du poids mouche ?
Economise beaucoup de RAM si il y a des tonnes d’objets similaires
78
Quels sont les inconvénients du poids mouche ?
Le code peut devenir très moche !
79
Quel est le principe de la Chaîne de responsabilité ?
On va construire des étapes, indépendantes des autres, puis on va construire un objet qui va nous permettre de définir l’ordre.
80
Quand utiliser la chaîne de responsabilité ?
Quand l’ordre varie durant l’execution (donc on peut pas l’hardcoder), ou quand l’ordre n’est pas connu à l’avance.
81
Quels sont les avantages de la chaine de responsabilité ?
On peut facilement ajouter un maillon, on peut définir lors du runtime l’ordre des étapes.
82
Quel est le principe du design pattern Commande ?
On sépare l’objet qui lance l’action (par exemple un bouton) de l’action en elle même. C’est le principe des événements dans Javascript.
83
Quand utiliser le design pattern Commande ?
Surtout dans le front, quand on veut créer des objets visuels, mais y associer une logique par dessus, sans devoir recréer des sous-classes.
84
Quels sont les avantages du design pattern Commande ?
On sépare le rendu visuel du traitement, on peut combiner facilement plusieurs traitement.
85
Quel est le principe du Mémento ?
On veut faire des sauvegardes d’un objet, pour pouvoir changer rapidement de version quand il le veut. On va implémenter 3 objets : la cible, le mémento (données sauvegardées), et le gardien, qui va créer des mémento et les charger)
86
Quand utiliser le Mémento ?
On veut implémenter une sauvegarde, ex avec un control Z, ou quand on veut sécuriser les données d’un objet.
87
Quels sont les avantages du Mémento ?
Simplifie le code de l’objet en laissant le gardien s’occupe de la sauvegarde et du rechargement.
88
Quels sont les inconvénients du Mémento ?
Si trop de snapshot, alors trop de RAM consumée. Il faut gérer les mémento trop anciens.
89
Quel est le principe de l’Observateur ?
On veut créer un watcher, de sorte que le diffuseur n’ai pas besoin d’hardcoder les abonnés (ceux qui écoutent). Ce sont plutôt les abonnés qui vont s’ajouter tous seuls.
90
Quand utiliser l’Observateur ?
Quand le nombre d’abonnés n’est pas connu à l’avance, ou que c’est variable dans le temps
91
Quels sont les avantages de l’Observateur ?
On peut facilement ajouter un nouvel abonné.
92
Quels sont les inconvénients de l’Observateur ?
Les abonnés sont avertis dans un ordre aléatoire.
93
Quel est le principe du design pattern Etat ?
Imaginons un hero, qui peut être empoisonné, blessé, brulé… Son comportement va être à chaque fois modifié. L’Etat va créer une sous classe pour chaque comportement, qui spécifier quel comportement adopter.
94
Quand utiliser le design pattern Etat ?
Quand un objet varie en fonction de son état, et qu’il y a beaucoup d’états. Si il est trop pollué par des blocs conditionnels, et trop de code dupliqué dans les états
95
Quel est l’avantage du design pattern Etat ?
Un état = une classe, donc responsabilité unique, ouvert/fermé, simplifie le code du contexte
96
Quel est l’inconvénient du design pattern Etat ?
Exagéré si peu d’états ou peu de transitions.
97
Quel est le principe du Visiteur ?
On va séparer les classes de données et les algorithmes.
98
Quelles sont les questions à se poser avant de faire des logs ?
Est ce que ce log est vraiment utile ? Est-ce que cette info n’existe pas déjà ailleurs ? Est ce que je vais log un gros objet ? Si oui, est ce que je peux logger seulement quelques infos de l’objet ? Est ce que l’info que je log va m’aider à debugger / comprendre le process ?
99
Quels sont les 4 niveaux de logs ?
ERROR, WARNING, INFO, DEBUG
100
Pourquoi les logs peuvent couter chers ?
Parce qu’ils prennent beacoup d’espace sur le disque
101
Que faut t’il avoir sur des logs ?
Le même pattern, pour pouvoir facilement les scrapper par la suite.
102
Que veut dire AOP ?
Aspect Oriented Programmation.
103
Quel est le principe de l’AOP ?
On sépare clairement le détails techniques du code. C’est à dire que l’on va cacher le principe de cache, de logs… pour rendre le code métier très simple et très clair.
104
Quels sont les 3 concepts de l’AOP ?
Le joint point (avant ou après la méthode ?), le point cut (Quelles méthodes ? Via une regex ?), l’aspect (quoi faire ?)
105
Que peut on mettre dans les aspects en AOP ?
Des logs, du cache, des transaction, des timers…
106
Comment développer facilement sur une machine distante ?
Avec l’extension remote dev sur VScode, en SSH
107
Qu’est ce que Mermaid JS ?
Un package qui permet de construire à partir d’un texte des diagrammes SVG
108
Quels sont les avantages de Mermaid JS ?
Plus besoin de glisser déposer les éléments, tout est en code, On peut versionner plus facilement, Les modifications sont BEAUCOUP, BEAUCOUP plus simples, On se prend plus la tête à relier les éléments à la main, Le bonus, il est intégrable avec docusaurus directement !
109
Quel est la bonne pratique avant de commencer un diagramme (quel outil utiliser) ?
Il faut regarder Mermaid JS avant de se lancer, pour voir si le diagramme que l’on souhaite faire est adapté. Sinon on peut se pencher du côté de D2.
110
Qu’est ce que D2 ?
Un langage de diagramme, comme Mermaid JS.
111
Comment les rayons cosmiques peuvent créer un bug ?
En modifiant les bits, et donc créer un bug.
112
Qu’est ce que gitmoji ?
Une convention de nommage des intentions des commits, en utilisant des emojis.
113
Quand utiliser les git subtree ?
Quand on veut inclure un autre répo dans notre répo. (pas en copiant collant hein)
114
Qu’est ce que gitsubtree ?
Fonctionnalité git qui permet d’ajouter un répo à un autre.
115
Que signifie le S de SOLID ?
Single Responsabilité : une classe ne doit avoir qu’un seul objectif métier ou technique
116
Que signifie le O de SOLID ?
Open Close : Créer des classes filles à la place de if instanceof, pour abstraire le code.
117
Que signifie le L de SOLID ?
Liskov Substitution : L’ajout d’une classe fille ne doit pas casser l’abstraction utilisant la classe mère.
118
Que signifie le I de SOLID ?
Interface Segregation : On divise en petites interface les objets qui dépendent d’une grosse interface. Qui peut le plus peut le moins.
119
Que signifie le D de SOLID ?
Dependency : Il vaut mieux utiliser une interface (ou classe abstraite) plutôt qu’une classe fille, ou une classe en dur.
120
Pourquoi le singleton est dangereux (antipattern) ?
C’est un goulot d’étranglement, car pleins d’utilisateurs dessus en même temps, les tests unitaires deviennent compliqués et le multithreading peut poser problème.
121
Pourquoi Null n’est pas aimé par certains développeurs ?
Car il peut remprésenter plusieurs choses (absent, incomplet, invalide…). Et qu’il n’est pas polymorphique (donc on est obligé d’ajouter des blocs if.)
122
Quelles sont les 7 principes de REST ?
Les URL pour faire le routage, les méthodes HTTP portent des informations, mise en cache possible, stateless, archi en couches, ajout de code à la demande, peut préciser le type de réponse voulu.
123
POST vs PULL vs PATCH ?
PUT décrit toute la ressource, créé si elle n’existe pas ou l’écrase. PUT est idempotent (même résultat à chaque fois). PATCH c’est comme PUT, mais pas obligé de décrire toute la ressource. POST peut définir aussi bien la création d’une ressource qu’une action à effectuer.
124
Que signifie le code de retour 201 en HTTP ?
Resource créée
125
Que signifie le code de retour 204 en HTTP ?
Ok mais pas de body
126
Que signifie le code de retour 204 en HTTP ?
Ok mais pas de body
127
A quoi sert le versioning d’une API ?
A pouvoir s’assurer que les clients qui tapaient dans les anciens schémas n’aient pas besoin de modifier leur code pour que ça marche encore. Et pour les devs, c’est de pouvoir s’assurer qu’on puisse modifier l’API sans impacter les clients.
128
Quelles sont les 5 méthodes pour gérer le versioning d’API ?
Aucun contrôle de version, Mettre la version dans l’URL, mettre la version en tant que paramètre dans l’URL, Mettre la version dans un header personnalisé, Mettre la version dans le Content-Type
129
Que faire si une version est trop vieille, qu’elle ne correspond plus au besoin métier ?
On peut la déclarer comme dépréciée, et donc rediriger avec une 301 l’api. Oblige donc le client a changer son code.
130
Qu’est ce que l’HATEOAS ?
Une technique d’autodocumentation de notre API : on va renvoyer dans le body de le ressource toutes les actions possibles, à travers quels URL et quelles méthodes HTTP utiliser. (on peut aussi préciser le schéma). Cela permet une navigation plus fluide pour le client.
